perm filename CLCLEA.3[COM,LSP] blob
sn#861898 filedate 1988-10-07 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00808 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00115 00002
C00116 00003 ∂19-Jun-88 2245 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
C00119 00004 ∂20-Jun-88 0729 CL-Cleanup-mailer KCL scoping bug?
C00127 00005 ∂20-Jun-88 0748 CL-Cleanup-mailer Common Lisp Semantics for Function Call
C00130 00006 ∂20-Jun-88 0921 CL-Cleanup-mailer Issue: COERCE-FROM-TYPE (Version 1)
C00137 00007 ∂20-Jun-88 1149 CL-Cleanup-mailer comments on draft proposals
C00140 00008 ∂20-Jun-88 1311 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 1)
C00152 00009 ∂20-Jun-88 1312 CL-Cleanup-mailer Issue: ALIST-NIL (Version 1)
C00159 00010 ∂20-Jun-88 1316 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
C00165 00011 ∂20-Jun-88 1411 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
C00171 00012 ∂20-Jun-88 1418 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
C00173 00013 ∂20-Jun-88 1546 CL-Cleanup-mailer STEP-ENVIRONMENT, version 3
C00179 00014 ∂20-Jun-88 1842 CL-Cleanup-mailer Issue: STEP-ENVIRONMENT, version 3
C00180 00015 ∂21-Jun-88 0003 CL-Cleanup-mailer
C00182 00016 ∂21-Jun-88 1739 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
C00185 00017 ∂21-Jun-88 1740 CL-Cleanup-mailer STEP-ENVIRONMENT, version 3
C00187 00018 ∂22-Jun-88 1004 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
C00193 00019 ∂22-Jun-88 1254 CL-Cleanup-mailer Issue: STREAM-CLASS-ACCESS (version 1)
C00196 00020 ∂22-Jun-88 1508 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
C00204 00021 ∂22-Jun-88 2258 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 1)
C00206 00022 ∂22-Jun-88 2306 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
C00208 00023 ∂22-Jun-88 2317 CL-Cleanup-mailer Re: Issue: TRACE-ERROR (Version 1)
C00211 00024 ∂22-Jun-88 2338 CL-Cleanup-mailer Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
C00213 00025 ∂23-Jun-88 0153 CL-Cleanup-mailer &key in defstruct :constructor arglists
C00217 00026 ∂23-Jun-88 0725 CL-Cleanup-mailer Re: Issue: TRACE-ERROR (Version 1)
C00225 00027 ∂23-Jun-88 0733 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
C00230 00028 ∂23-Jun-88 0738 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 1)
C00233 00029 ∂23-Jun-88 0842 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
C00235 00030 ∂23-Jun-88 1005 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 1)
C00248 00031 ∂23-Jun-88 1254 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
C00267 00032 ∂23-Jun-88 1412 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 1)
C00276 00033 ∂23-Jun-88 1516 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00278 00034 ∂24-Jun-88 0912 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00280 00035 ∂24-Jun-88 1058 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00298 00036 ∂24-Jun-88 1100 CL-Cleanup-mailer Issue: STRUCTURE-INFO (Version 1)
C00304 00037 ∂24-Jun-88 1149 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00306 00038 ∂24-Jun-88 1209 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00309 00039 ∂24-Jun-88 1225 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00311 00040 ∂24-Jun-88 1307 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00313 00041 ∂24-Jun-88 1552 CL-Cleanup-mailer EQUAL
C00319 00042 ∂24-Jun-88 1647 CL-Cleanup-mailer EQUAL
C00323 00043 ∂27-Jun-88 0753 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00328 00044 ∂27-Jun-88 0817 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00331 00045 ∂27-Jun-88 0834 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00335 00046 ∂27-Jun-88 1238 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C00343 00047 ∂27-Jun-88 1357 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 1)
C00349 00048 ∂28-Jun-88 0919 CL-Cleanup-mailer
C00352 00049 ∂28-Jun-88 0943 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00357 00050 ∂28-Jun-88 1000 CL-Cleanup-mailer
C00358 00051 ∂28-Jun-88 1041 CL-Cleanup-mailer Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5)
C00371 00052 ∂28-Jun-88 1100 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-UTILITY
C00376 00053 ∂28-Jun-88 1137 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)
C00384 00054 ∂28-Jun-88 1347 CL-Cleanup-mailer Issue: DOTTED-MACRO-FORMS (Version 1)
C00393 00055 ∂28-Jun-88 1353 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-UTILITY (Version 1)
C00399 00056 ∂28-Jun-88 1413 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
C00402 00057 ∂29-Jun-88 0931 CL-Cleanup-mailer
C00403 00058 ∂29-Jun-88 1013 CL-Cleanup-mailer
C00406 00059 ∂29-Jun-88 1054 CL-Cleanup-mailer RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
C00412 00060 ∂29-Jun-88 1114 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
C00418 00061 ∂29-Jun-88 1116 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
C00421 00062 ∂29-Jun-88 1136 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
C00425 00063 ∂29-Jun-88 1413 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-UTILITY
C00433 00064 ∂29-Jun-88 2336 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00435 00065 ∂30-Jun-88 0004 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00437 00066 ∂30-Jun-88 0623 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00439 00067 ∂30-Jun-88 0735 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00448 00068 ∂30-Jun-88 0803 CL-Cleanup-mailer EQUAL
C00451 00069 ∂30-Jun-88 0809 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00456 00070 ∂30-Jun-88 0927 CL-Cleanup-mailer various DEFSTRUCT issues
C00465 00071 ∂30-Jun-88 1145 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00472 00072 ∂30-Jun-88 1557 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C00474 00073 ∂30-Jun-88 1557 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C00476 00074 ∂01-Jul-88 0701 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00478 00075 ∂02-Jul-88 1158 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00488 00076 ∂05-Jul-88 0854 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C00494 00077 ∂05-Jul-88 1156 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00508 00078 ∂05-Jul-88 1454 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
C00520 00079 ∂05-Jul-88 1455 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 1)
C00533 00080 ∂05-Jul-88 1624 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00535 00081 ∂06-Jul-88 0720 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
C00545 00082 ∂06-Jul-88 1836 CL-Cleanup-mailer EQUAL-STRUCTURE
C00547 00083 ∂07-Jul-88 0824 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
C00561 00084 ∂07-Jul-88 0908 CL-Cleanup-mailer RE: Issue: SYMBOL-MACROLET-UTILITY
C00568 00085 ∂07-Jul-88 1136 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C00577 00086 ∂07-Jul-88 1308 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 1)
C00588 00087 ∂07-Jul-88 1312 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
C00595 00088 ∂08-Jul-88 0310 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
C00597 00089 ∂08-Jul-88 0541 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C00601 00090 ∂08-Jul-88 0542 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 1)
C00603 00091 ∂08-Jul-88 0545 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00607 00092 ∂08-Jul-88 0545 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00610 00093 ∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00615 00094 ∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00619 00095 ∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00629 00096 ∂08-Jul-88 1028 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00632 00097 ∂08-Jul-88 1420 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
C00643 00098 ∂08-Jul-88 1457 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
C00646 00099 ∂08-Jul-88 1522 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C00658 00100 ∂11-Jul-88 0856 CL-Cleanup-mailer subtypep vagueness
C00661 00101 ∂11-Jul-88 1023 CL-Cleanup-mailer Re: subtypep vagueness
C00663 00102 ∂11-Jul-88 1029 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00670 00103 ∂11-Jul-88 1034 CL-Cleanup-mailer Re: subtypep vagueness
C00672 00104 ∂11-Jul-88 1059 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C00675 00105 ∂11-Jul-88 1313 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
C00681 00106 ∂11-Jul-88 1418 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00686 00107 ∂11-Jul-88 1436 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00691 00108 ∂11-Jul-88 1944 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
C00693 00109 ∂12-Jul-88 0247 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00695 00110 ∂12-Jul-88 0926 CL-Cleanup-mailer package-clutter:reduce
C00696 00111 ∂12-Jul-88 1152 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00699 00112 ∂12-Jul-88 1253 CL-Cleanup-mailer Re: SUBTYPEP-TOO-VAGUE (initial draft)
C00703 00113 ∂12-Jul-88 1302 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
C00705 00114 ∂12-Jul-88 1305 CL-Cleanup-mailer Re: SUBTYPEP-TOO-VAGUE (initial draft)
C00707 00115 ∂12-Jul-88 1544 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00709 00116 ∂12-Jul-88 1555 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00712 00117 ∂12-Jul-88 1630 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00714 00118 ∂13-Jul-88 0853 CL-Cleanup-mailer an alternate BOGUS-FIXNUMS proposal
C00720 00119 ∂13-Jul-88 1221 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
C00723 00120 ∂13-Jul-88 1445 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
C00728 00121 ∂13-Jul-88 1543 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00731 00122 ∂14-Jul-88 1146 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
C00736 00123 ∂14-Jul-88 1538 CL-Cleanup-mailer Re: various DEFSTRUCT issues
C00738 00124 ∂14-Jul-88 2214 CL-Cleanup-mailer BOGUS-FIXNUMS, again
C00745 00125 ∂15-Jul-88 0013 CL-Cleanup-mailer an alternate BOGUS-FIXNUMS proposal
C00751 00126 ∂15-Jul-88 0110 CL-Cleanup-mailer re: issue BOGUS-FIXNUMS
C00757 00127 ∂15-Jul-88 0555 CL-Cleanup-mailer Issue: BOGUS-FIXNUMS
C00764 00128 ∂17-Jul-88 0820 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00773 00129 ∂18-Jul-88 0914 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00781 00130 ∂18-Jul-88 1345 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00783 00131 ∂18-Jul-88 1403 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00788 00132 ∂18-Jul-88 1433 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00793 00133 ∂18-Jul-88 1552 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
C00801 00134 ∂18-Jul-88 1555 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00804 00135 ∂18-Jul-88 1556 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
C00806 00136 ∂18-Jul-88 1957 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00817 00137 ∂18-Jul-88 2033 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00819 00138 ∂19-Jul-88 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00830 00139 ∂19-Jul-88 0823 CL-Cleanup-mailer EQUAL, and hash tables, and value/object distinctions
C00835 00140 ∂19-Jul-88 1342 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 2
C00842 00141 ∂19-Jul-88 1350 CL-Cleanup-mailer more on BOGUS-FIXNUMS
C00849 00142 ∂19-Jul-88 1453 CL-Cleanup-mailer more on BOGUS-FIXNUMS
C00851 00143 ∂20-Jul-88 1147 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00854 00144 ∂20-Jul-88 1217 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00857 00145 ∂20-Jul-88 1535 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00864 00146 ∂20-Jul-88 1712 CL-Cleanup-mailer re: encourage no side-effect garbage
C00866 00147 ∂20-Jul-88 1732 CL-Cleanup-mailer proposal: encourage no side-effect garbage
C00871 00148 ∂20-Jul-88 1751 CL-Cleanup-mailer proposal: eliminate forced consing
C00891 00149 ∂21-Jul-88 0622 CL-Cleanup-mailer Re: proposal: encourage no side-effect garbage
C00894 00150 ∂21-Jul-88 0623 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00901 00151 ∂21-Jul-88 0643 CL-Cleanup-mailer Re: proposal: eliminate forced consing
C00903 00152 ∂21-Jul-88 0803 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00906 00153 ∂21-Jul-88 0814 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00907 00154 ∂21-Jul-88 0825 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00910 00155 ∂21-Jul-88 0833 CL-Cleanup-mailer [Masinter.pa: Re: questions]
C00920 00156 ∂21-Jul-88 0936 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00924 00157 ∂21-Jul-88 1044 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C00932 00158 ∂21-Jul-88 1205 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00935 00159 ∂21-Jul-88 1211 CL-Cleanup-mailer proposal: eliminate forced consing
C00937 00160 ∂21-Jul-88 1302 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00943 00161 ∂21-Jul-88 1308 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00945 00162 ∂21-Jul-88 1351 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00946 00163 ∂21-Jul-88 1417 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00957 00164 ∂21-Jul-88 1515 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00963 00165 ∂21-Jul-88 1537 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00966 00166 ∂21-Jul-88 1546 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00973 00167 ∂21-Jul-88 1633 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00977 00168 ∂22-Jul-88 0642 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00980 00169 ∂22-Jul-88 0649 CL-Cleanup-mailer FIXNUM's aren't Bogus!
C00989 00170 ∂22-Jul-88 0928 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00992 00171 ∂22-Jul-88 0957 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C00995 00172 ∂22-Jul-88 1000 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C00999 00173 ∂22-Jul-88 1001 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
C01001 00174 ∂22-Jul-88 1002 CL-Cleanup-mailer Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
C01005 00175 ∂22-Jul-88 1005 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01009 00176 ∂22-Jul-88 1006 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (Version 1)
C01011 00177 ∂22-Jul-88 1026 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01015 00178 ∂22-Jul-88 1133 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C01018 00179 ∂22-Jul-88 1259 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01021 00180 ∂22-Jul-88 1335 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01029 00181 ∂22-Jul-88 1346 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01031 00182 ∂22-Jul-88 1910 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
C01036 00183 ∂23-Jul-88 0838 CL-Cleanup-mailer Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C01038 00184 ∂24-Jul-88 2306 CL-Cleanup-mailer Re: [Masinter.pa: Re: questions]
C01041 00185 ∂25-Jul-88 0716 CL-Cleanup-mailer Re: [Masinter.pa: Re: questions]
C01043 00186 ∂26-Jul-88 1656 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
C01050 00187 ∂26-Jul-88 1657 CL-Cleanup-mailer ISSUE: DEFSTRUCT-REDEFINITION
C01056 00188 ∂26-Jul-88 1658 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
C01060 00189 ∂26-Jul-88 1659 CL-Cleanup-mailer A lambda question
C01062 00190 ∂26-Jul-88 1725 CL-Cleanup-mailer Re: A lambda question
C01064 00191 ∂28-Jul-88 1201 CL-Cleanup-mailer Issue BOGUS-FIXNUMS (Version 2)
C01074 00192 ∂28-Jul-88 1917 CL-Cleanup-mailer MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
C01077 00193 ∂28-Jul-88 2109 CL-Cleanup-mailer Re: Issue BOGUS-FIXNUMS (Version 2)
C01079 00194 ∂28-Jul-88 2200 CL-Cleanup-mailer Re: ISSUE: DEFSTRUCT-REDEFINITION
C01081 00195 ∂29-Jul-88 0803 CL-Cleanup-mailer Re: ISSUE: DEFSTRUCT-REDEFINITION
C01083 00196 ∂29-Jul-88 1410 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS
C01096 00197 ∂29-Jul-88 2306 CL-Cleanup-mailer bignums
C01100 00198 ∂31-Jul-88 1340 CL-Cleanup-mailer Issue BOGUS-FIXNUMS (Version 2)
C01108 00199 ∂01-Aug-88 0716 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)
C01111 00200 ∂01-Aug-88 0742 CL-Cleanup-mailer A lambda question
C01117 00201 ∂01-Aug-88 1024 CL-Cleanup-mailer A lambda question (a.k.a. issue FUNCTION-DEFINITION)
C01119 00202 ∂01-Aug-88 1041 CL-Cleanup-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C01124 00203 ∂01-Aug-88 1058 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
C01131 00204 ∂01-Aug-88 1133 CL-Cleanup-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
C01136 00205 ∂01-Aug-88 2023 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
C01138 00206 ∂02-Aug-88 0717 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
C01143 00207 ∂04-Aug-88 1522 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
C01148 00208 ∂04-Aug-88 1740 CL-Cleanup-mailer A lambda question
C01150 00209 ∂04-Aug-88 2349 CL-Cleanup-mailer bignums
C01155 00210 ∂05-Aug-88 1006 CL-Cleanup-mailer issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
C01160 00211 ∂05-Aug-88 1024 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1)
C01163 00212 ∂16-Aug-88 1541 CL-Cleanup-mailer Issue: NTH-VALUE (Version 1)
C01168 00213 ∂16-Aug-88 1627 CL-Cleanup-mailer Issue: NTH-VALUE (Version 1)
C01172 00214 ∂16-Aug-88 1641 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 1)
C01174 00215 ∂18-Aug-88 1114 CL-Cleanup-mailer (LET ((var)) ...) and (PROG ((var)) ...)
C01177 00216 ∂18-Aug-88 1406 CL-Cleanup-mailer Issue VARIABLE-LIST-ASYMMETRY
C01179 00217 ∂18-Aug-88 1631 CL-Cleanup-mailer Issue VARIABLE-LIST-ASYMMETRY
C01181 00218 ∂21-Aug-88 1521 CL-Cleanup-mailer new item: RANGE-OF-COUNT-KEYWORD
C01188 00219 ∂22-Aug-88 0841 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
C01201 00220 ∂22-Aug-88 0948 CL-Cleanup-mailer Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
C01203 00221 ∂22-Aug-88 2241 CL-Cleanup-mailer Issue "Eliminate forced consing" re-visited
C01227 00222 ∂23-Aug-88 0740 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01233 00223 ∂23-Aug-88 0819 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01237 00224 ∂23-Aug-88 1114 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01242 00225 ∂23-Aug-88 1158 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01249 00226 ∂23-Aug-88 1230 CL-Cleanup-mailer Issue "Eliminate forced consing" re-visited
C01252 00227 ∂23-Aug-88 1650 CL-Cleanup-mailer loop vs. sequence functions
C01259 00228 ∂23-Aug-88 2308 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01261 00229 ∂23-Aug-88 2317 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01263 00230 ∂24-Aug-88 0808 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01269 00231 ∂24-Aug-88 2030 CL-Cleanup-mailer required libraries to reduce image size
C01271 00232 ∂24-Aug-88 2107 CL-Cleanup-mailer oops, important mis-speak in previous mail, correction included
C01273 00233 ∂24-Aug-88 2111 CL-Cleanup-mailer brief summary of issue "Eliminate Forced Consing"
C01276 00234 ∂25-Aug-88 1056 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
C01281 00235 ∂25-Aug-88 1721 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
C01283 00236 ∂27-Aug-88 1111 CL-Cleanup-mailer Issue ELIMINATE FORCED CONSING (Version 2) [formerly "Eliminate forced consing" re-visited]
C01293 00237 ∂30-Aug-88 1158 CL-Cleanup-mailer DISALLOW-CLOSED-STREAM-FUNCTIONS
C01297 00238 ∂30-Aug-88 1201 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
C01301 00239 ∂30-Aug-88 1201 CL-Cleanup-mailer ARGUMENTS-UNDERSPECIFIED
C01305 00240 ∂31-Aug-88 1513 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01315 00241 ∂31-Aug-88 1632 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
C01323 00242 ∂31-Aug-88 2112 CL-Cleanup-mailer 3 new cleanups
C01325 00243 ∂31-Aug-88 2112 CL-Cleanup-mailer lambda-cleanup
C01332 00244 ∂31-Aug-88 2112 CL-Cleanup-mailer list type cleanup
C01336 00245 ∂31-Aug-88 2113 CL-Cleanup-mailer CLOS standard class cleanup
C01349 00246 ∂31-Aug-88 2118 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01352 00247 ∂01-Sep-88 0847 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
C01355 00248 ∂01-Sep-88 1040 CL-Cleanup-mailer Re: CLOS standard class cleanup
C01360 00249 ∂01-Sep-88 1105 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01363 00250 ∂01-Sep-88 1123 CL-Cleanup-mailer lambda-cleanup
C01365 00251 ∂01-Sep-88 1210 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01367 00252 ∂01-Sep-88 1422 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
C01373 00253 ∂01-Sep-88 1437 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C01377 00254 ∂01-Sep-88 2309 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
C01382 00255 ∂02-Sep-88 1357 CL-Cleanup-mailer reaching closure on open cleanup items
C01384 00256 ∂02-Sep-88 1636 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly
C01386 00257 ∂02-Sep-88 1637 CL-Cleanup-mailer Re: RETURN-VALUES-UNSPECIFIED
C01388 00258 ∂02-Sep-88 1844 CL-Cleanup-mailer Ooops! Issue: LAMBDA-CAR-OF-FORM
C01390 00259 ∂02-Sep-88 1844 CL-Cleanup-mailer Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR)
C01392 00260 ∂02-Sep-88 1845 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
C01394 00261 ∂02-Sep-88 1845 CL-Cleanup-mailer Re: required libraries to reduce image size
C01397 00262 ∂02-Sep-88 1845 CL-Cleanup-mailer Re: required libraries to reduce image size
C01400 00263 ∂02-Sep-88 1845 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
C01402 00264 ∂04-Sep-88 1447 CL-Cleanup-mailer [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL
C01409 00265 ∂04-Sep-88 1521 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
C01414 00266 ∂04-Sep-88 1559 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1)
C01417 00267 ∂04-Sep-88 1617 CL-Cleanup-mailer Issue: COERCE (Version 1) vs COERCE-FROM-TYPE
C01419 00268 ∂05-Sep-88 1324 CL-Cleanup-mailer Re: Potential issues?
C01423 00269 ∂05-Sep-88 1417 CL-Cleanup-mailer Potential issues?
C01429 00270 ∂06-Sep-88 1010 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
C01431 00271 ∂06-Sep-88 1753 CL-Cleanup-mailer Re: RETURN-VALUES-UNSPECIFIED
C01432 00272 ∂07-Sep-88 0001 CL-Cleanup-mailer Revised ELIMINATE-CONSING-PROPOSAL, version 3
C01457 00273 ∂07-Sep-88 0219 CL-Cleanup-mailer discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
C01474 00274 ∂07-Sep-88 1155 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
C01479 00275 ∂07-Sep-88 1225 CL-Cleanup-mailer discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
C01482 00276 ∂07-Sep-88 1226 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
C01490 00277 ∂07-Sep-88 1423 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE
C01494 00278 ∂07-Sep-88 1634 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 1)
C01506 00279 ∂07-Sep-88 1825 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
C01508 00280 ∂07-Sep-88 1840 CL-Cleanup-mailer SYMBOL-MACROFLET
C01512 00281 ∂07-Sep-88 1843 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1)
C01516 00282 ∂07-Sep-88 1853 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
C01518 00283 ∂07-Sep-88 1911 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
C01520 00284 ∂07-Sep-88 1913 CL-Cleanup-mailer [Masinter.pa: Re: questions]
C01524 00285 ∂07-Sep-88 1918 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C01526 00286 ∂07-Sep-88 1923 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
C01529 00287 ∂07-Sep-88 1935 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
C01534 00288 ∂07-Sep-88 1942 CL-Cleanup-mailer Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
C01539 00289 ∂07-Sep-88 1956 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
C01541 00290 ∂07-Sep-88 2005 CL-Cleanup-mailer symbol-macrolet-semantics, symbol-macrolet-utility
C01545 00291 ∂07-Sep-88 2004 Common-Lisp-Object-System-mailer symbol-macrolet-semantics, symbol-macrolet-utility
C01549 00292 ∂07-Sep-88 2027 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 2
C01555 00293 ∂07-Sep-88 2241 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
C01558 00294 ∂08-Sep-88 1143 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C01561 00295 ∂08-Sep-88 1143 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C01564 00296 ∂08-Sep-88 1147 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
C01567 00297 ∂08-Sep-88 1254 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C01570 00298 ∂08-Sep-88 1346 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
C01572 00299 ∂08-Sep-88 1634 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (Version 1)
C01574 00300 ∂12-Sep-88 1147 CL-Cleanup-mailer Issue: DESCRIBE-INTERACTIVE (Version 1)
C01580 00301 ∂12-Sep-88 1334 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
C01581 00302 ∂12-Sep-88 1337 CL-Cleanup-mailer Issue: LAMBDA-FORM
C01582 00303 ∂12-Sep-88 1341 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION
C01584 00304 ∂12-Sep-88 1345 CL-Cleanup-mailer Issue: NTH-VALUE
C01586 00305 ∂12-Sep-88 1353 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
C01587 00306 ∂12-Sep-88 1417 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
C01589 00307 ∂12-Sep-88 1418 CL-Cleanup-mailer Issue: BOGUS-FIXNUMS
C01591 00308 ∂12-Sep-88 1421 CL-Cleanup-mailer Issue: VARIABLE-LIST-ASYMMETRY
C01592 00309 ∂12-Sep-88 1424 CL-Cleanup-mailer issue TRUENAME-SYNTAX-ONLY
C01600 00310 ∂12-Sep-88 1507 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C01605 00311 ∂12-Sep-88 1706 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C01607 00312 ∂12-Sep-88 1709 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
C01610 00313 ∂12-Sep-88 1727 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C01616 00314 ∂12-Sep-88 1747 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
C01621 00315 ∂12-Sep-88 1814 CL-Cleanup-mailer issue TRUENAME-SYNTAX-ONLY
C01627 00316 ∂13-Sep-88 0232 CL-Cleanup-mailer Re: COERCE-FROM-TYPE and TYPE-OF
C01630 00317 ∂13-Sep-88 0633 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
C01632 00318 ∂13-Sep-88 0637 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION
C01634 00319 ∂13-Sep-88 0649 CL-Cleanup-mailer Issue PROCLAIM-SCOPE
C01636 00320 ∂13-Sep-88 0703 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER
C01638 00321 ∂13-Sep-88 0713 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED
C01640 00322 ∂13-Sep-88 0714 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED
C01641 00323 ∂13-Sep-88 0708 Common-Lisp-Object-System-mailer RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C01644 00324 ∂13-Sep-88 0725 CL-Cleanup-mailer Re: COERCE-FROM-TYPE and TYPE-OF
C01647 00325 ∂13-Sep-88 0825 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C01656 00326 ∂13-Sep-88 0916 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
C01664 00327 ∂13-Sep-88 0935 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
C01668 00328 ∂13-Sep-88 1109 CL-Cleanup-mailer SYMBOL-MACROFLET
C01673 00329 ∂13-Sep-88 1131 CL-Cleanup-mailer SYMBOL-MACROFLET
C01675 00330 ∂13-Sep-88 1145 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
C01679 00331 ∂13-Sep-88 1212 CL-Cleanup-mailer SYMBOL-MACROFLET
C01682 00332 ∂13-Sep-88 1213 CL-Cleanup-mailer Exponent sign printing with ~E
C01688 00333 ∂13-Sep-88 1214 CL-Cleanup-mailer SYMBOL-MACROFLET
C01692 00334 ∂13-Sep-88 1216 CL-Cleanup-mailer SYMBOL-MACROFLET
C01696 00335 ∂13-Sep-88 1232 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
C01700 00336 ∂13-Sep-88 1234 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
C01703 00337 ∂13-Sep-88 1238 CL-Cleanup-mailer Issue: TAILP-NIL (version 1)
C01706 00338 ∂13-Sep-88 1240 CL-Cleanup-mailer SYMBOL-MACROFLET
C01711 00339 ∂13-Sep-88 1459 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01717 00340 ∂13-Sep-88 1502 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
C01720 00341 ∂13-Sep-88 1542 CL-Cleanup-mailer Issue: TAILP-NIL (Version 2)
C01728 00342 ∂13-Sep-88 1550 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01732 00343 ∂13-Sep-88 1604 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
C01736 00344 ∂13-Sep-88 1612 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
C01738 00345 ∂13-Sep-88 2331 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01742 00346 ∂14-Sep-88 0007 CL-Cleanup-mailer Re: Exponent sign printing with ~E
C01744 00347 ∂14-Sep-88 0123 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01746 00348 ∂14-Sep-88 0244 CL-Cleanup-mailer Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
C01749 00349 ∂14-Sep-88 0635 CL-Cleanup-mailer RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
C01751 00350 ∂14-Sep-88 0651 CL-Cleanup-mailer RE: Issue: TAILP-NIL (Version 2)
C01753 00351 ∂14-Sep-88 0721 CL-Cleanup-mailer RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C01755 00352 ∂14-Sep-88 0730 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES
C01757 00353 ∂14-Sep-88 0748 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
C01759 00354 ∂14-Sep-88 0804 CL-Cleanup-mailer Issue: ALIST-NIL
C01761 00355 ∂14-Sep-88 0924 CL-Cleanup-mailer Issue: ALIST-NIL
C01764 00356 ∂14-Sep-88 0934 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
C01768 00357 ∂14-Sep-88 0934 CL-Cleanup-mailer RE: Issue: ALIST-NIL
C01770 00358 ∂14-Sep-88 0944 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C01778 00359 ∂14-Sep-88 1010 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
C01781 00360 ∂14-Sep-88 1020 CL-Cleanup-mailer RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C01783 00361 ∂14-Sep-88 1031 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01785 00362 ∂14-Sep-88 1130 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C01787 00363 ∂14-Sep-88 1226 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 2)
C01789 00364 ∂14-Sep-88 1233 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
C01801 00365 ∂14-Sep-88 1321 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
C01803 00366 ∂14-Sep-88 1322 CL-Cleanup-mailer not about Issue: HASH-TABLE-ACCESS (version 1)
C01806 00367 ∂14-Sep-88 1322 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
C01818 00368 ∂14-Sep-88 1329 CL-Cleanup-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C01825 00369 ∂14-Sep-88 1458 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
C01830 00370 ∂14-Sep-88 2011 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
C01839 00371 ∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-REDEFINITION
C01842 00372 ∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C01844 00373 ∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
C01846 00374 ∂14-Sep-88 2207 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
C01851 00375 ∂14-Sep-88 2213 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
C01854 00376 ∂14-Sep-88 2222 CL-Cleanup-mailer re: encourage no side-effect garbage
C01856 00377 ∂14-Sep-88 2331 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
C01859 00378 ∂15-Sep-88 0018 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 1)
C01861 00379 ∂15-Sep-88 0018 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
C01863 00380 ∂15-Sep-88 0053 CL-Cleanup-mailer Committee meeting
C01865 00381 ∂15-Sep-88 0117 CL-Cleanup-mailer Re: Issue FIXNUM-NONPORTABLE (Version 1)
C01872 00382 ∂15-Sep-88 1029 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 1)
C01874 00383 ∂15-Sep-88 1029 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
C01876 00384 ∂15-Sep-88 1250 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C01879 00385 ∂15-Sep-88 1344 CL-Cleanup-mailer Re: Virginia and Hawaii X3J13 meetings
C01881 00386 ∂15-Sep-88 1351 CL-Cleanup-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
C01887 00387 ∂15-Sep-88 1633 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C01891 00388 ∂15-Sep-88 1852 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 1)
C01905 00389 ∂16-Sep-88 0005 CL-Cleanup-mailer Re: Issue: HASH-TABLE-ACCESS (version 1)
C01908 00390 ∂16-Sep-88 0145 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C01911 00391 ∂16-Sep-88 0156 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
C01913 00392 ∂16-Sep-88 0202 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
C01915 00393 ∂16-Sep-88 0241 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 1)
C01917 00394 ∂16-Sep-88 0755 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
C01925 00395 ∂16-Sep-88 0837 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
C01939 00396 ∂16-Sep-88 1603 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
C01943 00397 ∂16-Sep-88 1629 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C01945 00398 ∂16-Sep-88 1752 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
C01947 00399 ∂16-Sep-88 1752 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C01950 00400 ∂16-Sep-88 2307 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C01953 00401 ∂17-Sep-88 0907 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
C01956 00402 ∂17-Sep-88 1320 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C01959 00403 ∂17-Sep-88 1414 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C01963 00404 ∂17-Sep-88 1504 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
C01971 00405 ∂17-Sep-88 1514 CL-Cleanup-mailer Re: list type cleanup
C01975 00406 ∂17-Sep-88 1517 CL-Cleanup-mailer [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue:
C02004 00407 ∂17-Sep-88 1519 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
C02008 00408 ∂17-Sep-88 1620 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C02013 00409 ∂17-Sep-88 1622 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 5)
C02015 00410 ∂17-Sep-88 1648 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
C02018 00411 ∂18-Sep-88 1217 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
C02021 00412 ∂18-Sep-88 1218 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
C02024 00413 ∂18-Sep-88 1234 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
C02026 00414 ∂18-Sep-88 1241 CL-Cleanup-mailer Re: Issue FIXNUM-NONPORTABLE (Version 1)
C02028 00415 ∂18-Sep-88 1250 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
C02030 00416 ∂18-Sep-88 1253 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
C02032 00417 ∂18-Sep-88 1323 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02036 00418 ∂18-Sep-88 1343 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
C02039 00419 ∂18-Sep-88 1432 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
C02042 00420 ∂18-Sep-88 1632 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 5)
C02045 00421 ∂18-Sep-88 2235 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02047 00422 ∂19-Sep-88 0853 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 5)
C02050 00423 ∂19-Sep-88 0933 CL-Compiler-mailer Issue: LOAD-TIME-EVAL
C02054 00424 ∂19-Sep-88 1224 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD
C02056 00425 ∂19-Sep-88 1236 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
C02058 00426 ∂19-Sep-88 1259 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE
C02060 00427 ∂19-Sep-88 1308 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02072 00428 ∂19-Sep-88 1429 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C02075 00429 ∂19-Sep-88 1431 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
C02084 00430 ∂19-Sep-88 1438 CL-Cleanup-mailer Re: CL-CLEANUP committee mtg's
C02086 00431 ∂19-Sep-88 1439 CL-Editorial-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C02095 00432 ∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: NTH-VALUE
C02097 00433 ∂19-Sep-88 1505 CL-Cleanup-mailer Issue writeups
C02100 00434 ∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C02102 00435 ∂19-Sep-88 1512 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
C02105 00436 ∂19-Sep-88 1542 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
C02116 00437 ∂19-Sep-88 1618 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
C02119 00438 ∂19-Sep-88 1636 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
C02122 00439 ∂19-Sep-88 1658 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
C02126 00440 ∂19-Sep-88 1715 CL-Cleanup-mailer Re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
C02129 00441 ∂19-Sep-88 1752 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C02131 00442 ∂19-Sep-88 1808 CL-Cleanup-mailer ARGUMENTS-UNDERSPECIFIED
C02138 00443 ∂19-Sep-88 1810 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
C02143 00444 ∂19-Sep-88 2014 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
C02147 00445 ∂19-Sep-88 2036 CL-Cleanup-mailer Issue: TAILP-NIL (version 1)
C02149 00446 ∂19-Sep-88 2222 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C02151 00447 ∂19-Sep-88 2342 CL-Cleanup-mailer Re: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C02154 00448 ∂20-Sep-88 0022 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
C02162 00449 ∂20-Sep-88 0028 CL-Cleanup-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
C02166 00450 ∂20-Sep-88 0039 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
C02168 00451 ∂20-Sep-88 0040 CL-Cleanup-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
C02170 00452 ∂20-Sep-88 0127 CL-Cleanup-mailer Re: Issue: STACK-LET (Version 1)
C02172 00453 ∂20-Sep-88 0129 CL-Cleanup-mailer Issue: STANDARD-CLASS-OVERHEAD
C02174 00454 ∂20-Sep-88 0218 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES
C02178 00455 ∂20-Sep-88 0927 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02184 00456 ∂20-Sep-88 1005 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
C02186 00457 ∂20-Sep-88 1019 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02195 00458 ∂20-Sep-88 1024 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES
C02199 00459 ∂20-Sep-88 1038 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02202 00460 ∂20-Sep-88 1044 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02206 00461 ∂20-Sep-88 1047 CL-Cleanup-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C02209 00462 ∂20-Sep-88 1151 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C02211 00463 ∂20-Sep-88 1201 CL-Cleanup-mailer (only slightly about) Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C02216 00464 ∂20-Sep-88 1210 CL-Cleanup-mailer message references
C02220 00465 ∂20-Sep-88 1258 CL-Cleanup-mailer clcleanup mail archives
C02222 00466 ∂20-Sep-88 1649 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02228 00467 ∂20-Sep-88 1715 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02230 00468 ∂20-Sep-88 1721 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02236 00469 ∂20-Sep-88 1746 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02239 00470 ∂20-Sep-88 1800 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02247 00471 ∂20-Sep-88 1817 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
C02249 00472 ∂20-Sep-88 1817 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (version 1)
C02251 00473 ∂20-Sep-88 1817 Common-Lisp-Object-System-mailer Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02253 00474 ∂20-Sep-88 1836 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
C02256 00475 ∂20-Sep-88 1836 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02260 00476 ∂20-Sep-88 1909 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 3)
C02262 00477 ∂20-Sep-88 1920 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02265 00478 ∂20-Sep-88 1921 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02269 00479 ∂20-Sep-88 1944 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02275 00480 ∂20-Sep-88 1959 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02277 00481 ∂20-Sep-88 2001 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02280 00482 ∂20-Sep-88 2004 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02284 00483 ∂20-Sep-88 2008 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
C02287 00484 ∂20-Sep-88 2029 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
C02291 00485 ∂20-Sep-88 2044 CL-Cleanup-mailer message references
C02295 00486 ∂20-Sep-88 2126 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02299 00487 ∂20-Sep-88 2131 CL-Cleanup-mailer Re: message references
C02300 00488 ∂20-Sep-88 2132 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02303 00489 ∂20-Sep-88 2326 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02305 00490 ∂21-Sep-88 0035 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
C02307 00491 ∂21-Sep-88 0052 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02309 00492 ∂21-Sep-88 0111 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
C02315 00493 ∂21-Sep-88 0135 CL-Cleanup-mailer Issue: ALIST-NIL (Version 3)
C02322 00494 ∂21-Sep-88 0148 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
C02327 00495 ∂21-Sep-88 0240 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
C02329 00496 ∂21-Sep-88 0249 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
C02332 00497 ∂21-Sep-88 0306 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 1)
C02334 00498 ∂21-Sep-88 0319 CL-Cleanup-mailer Re: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
C02336 00499 ∂21-Sep-88 0845 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (version 1)
C02338 00500 ∂21-Sep-88 0906 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02342 00501 ∂21-Sep-88 0923 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02346 00502 ∂21-Sep-88 0950 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02351 00503 ∂21-Sep-88 1006 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
C02354 00504 ∂21-Sep-88 1036 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION (version 1)
C02359 00505 ∂21-Sep-88 1050 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02366 00506 ∂21-Sep-88 1059 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
C02376 00507 ∂21-Sep-88 1126 CL-Cleanup-mailer message references
C02379 00508 ∂21-Sep-88 1126 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02384 00509 ∂21-Sep-88 1126 CL-Compiler-mailer Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
C02393 00510 ∂21-Sep-88 1138 CL-Cleanup-mailer Re: message references
C02395 00511 ∂21-Sep-88 1153 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02404 00512 ∂21-Sep-88 1300 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02407 00513 ∂21-Sep-88 1302 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
C02409 00514 ∂21-Sep-88 1321 CL-Compiler-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02413 00515 ∂21-Sep-88 1329 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02417 00516 ∂21-Sep-88 1340 CL-Compiler-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02419 00517 ∂21-Sep-88 1403 CL-Cleanup-mailer Issue: PRINT-PRETTY-HOOK (version 1)
C02425 00518 ∂21-Sep-88 1408 CL-Compiler-mailer Re: Issue: LOAD-TIME-EVAL (Version 6)
C02430 00519 ∂21-Sep-88 1436 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02434 00520 ∂21-Sep-88 1525 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02440 00521 ∂21-Sep-88 1718 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
C02449 00522 ∂21-Sep-88 2329 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02451 00523 ∂22-Sep-88 0728 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02453 00524 ∂22-Sep-88 0741 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02458 00525 ∂22-Sep-88 0814 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02460 00526 ∂22-Sep-88 0852 CL-Cleanup-mailer Re: Issue: FUNCTION-DECLARATION (version 1)
C02464 00527 ∂22-Sep-88 0932 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02468 00528 ∂22-Sep-88 0932 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C02471 00529 ∂22-Sep-88 0941 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
C02475 00530 ∂22-Sep-88 0946 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02478 00531 ∂22-Sep-88 1007 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 2)
C02483 00532 ∂22-Sep-88 1015 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
C02486 00533 ∂22-Sep-88 1041 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 3
C02496 00534 ∂22-Sep-88 1047 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C02505 00535 ∂22-Sep-88 1413 CL-Cleanup-mailer CLOS in the standard
C02509 00536 ∂22-Sep-88 1722 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
C02512 00537 ∂22-Sep-88 1727 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
C02514 00538 ∂22-Sep-88 1923 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02522 00539 ∂22-Sep-88 2211 CL-Cleanup-mailer Re: Issue: DECLARE-FUNCTION-AMBIGUITY (version 1)
C02525 00540 ∂22-Sep-88 2230 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 3)
C02532 00541 ∂22-Sep-88 2249 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 3)
C02534 00542 ∂22-Sep-88 2253 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 3)
C02535 00543 ∂23-Sep-88 0017 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
C02540 00544 ∂23-Sep-88 0021 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
C02545 00545 ∂23-Sep-88 0125 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02560 00546 ∂23-Sep-88 0125 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
C02563 00547 ∂23-Sep-88 0134 CL-Cleanup-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
C02569 00548 ∂23-Sep-88 0242 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 3)
C02575 00549 ∂23-Sep-88 0243 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE (Version 2)
C02583 00550 ∂23-Sep-88 0709 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
C02588 00551 ∂23-Sep-88 0847 CL-Cleanup-mailer Issue: PRINT-PRETTY-HOOK (version 1)
C02590 00552 ∂23-Sep-88 0901 CL-Compiler-mailer Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
C02593 00553 ∂23-Sep-88 0913 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C02619 00554 ∂23-Sep-88 1353 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
C02621 00555 ∂23-Sep-88 1434 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
C02623 00556 ∂23-Sep-88 1447 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02626 00557 ∂23-Sep-88 1539 CL-Cleanup-mailer away....
C02628 00558 ∂23-Sep-88 1705 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02636 00559 ∂23-Sep-88 1946 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
C02638 00560 ∂24-Sep-88 1634 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02653 00561 ∂24-Sep-88 1635 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02657 00562 ∂24-Sep-88 1732 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02659 00563 ∂26-Sep-88 1206 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02662 00564 ∂26-Sep-88 1246 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02667 00565 ∂26-Sep-88 1412 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02669 00566 ∂26-Sep-88 1436 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02673 00567 ∂26-Sep-88 1455 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02678 00568 ∂26-Sep-88 1523 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02681 00569 ∂26-Sep-88 1719 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
C02687 00570 ∂26-Sep-88 1724 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02689 00571 ∂26-Sep-88 1739 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 3)
C02692 00572 ∂26-Sep-88 1756 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02695 00573 ∂26-Sep-88 1934 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
C02697 00574 ∂26-Sep-88 2043 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
C02699 00575 ∂26-Sep-88 2103 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02702 00576 ∂26-Sep-88 2106 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02704 00577 ∂26-Sep-88 2139 CL-Cleanup-mailer Issue: STREAM-INFO (Version 5)
C02706 00578 ∂26-Sep-88 2154 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
C02716 00579 ∂26-Sep-88 2302 CL-Cleanup-mailer Issue HASH-TABLE-TESTS
C02724 00580 ∂27-Sep-88 0504 CL-Cleanup-mailer Moon@stony-brook.scrc.symbolics.com
C02726 00581 ∂27-Sep-88 0728 CL-Cleanup-mailer Re: Moon@stony-brook.scrc.symbolics.com
C02728 00582 ∂27-Sep-88 0927 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
C02732 00583 ∂27-Sep-88 0936 CL-Cleanup-mailer Issue HASH-TABLE-TESTS (Version 1)
C02734 00584 ∂27-Sep-88 1006 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02737 00585 ∂27-Sep-88 1039 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02740 00586 ∂27-Sep-88 1055 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02745 00587 ∂27-Sep-88 1724 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 4)
C02756 00588 ∂27-Sep-88 1928 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
C02759 00589 ∂27-Sep-88 2256 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
C02778 00590 ∂27-Sep-88 2318 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (?)
C02782 00591 ∂27-Sep-88 2359 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02786 00592 ∂28-Sep-88 0852 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02791 00593 ∂28-Sep-88 0908 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 7)
C02797 00594 ∂28-Sep-88 0914 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
C02801 00595 ∂28-Sep-88 0914 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 7)
C02807 00596 ∂28-Sep-88 0956 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (?)
C02812 00597 ∂28-Sep-88 1049 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
C02816 00598 ∂28-Sep-88 1102 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
C02819 00599 ∂28-Sep-88 1156 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
C02822 00600 ∂28-Sep-88 1307 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02824 00601 ∂28-Sep-88 1311 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02827 00602 ∂28-Sep-88 1322 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
C02832 00603 ∂28-Sep-88 1355 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
C02836 00604 ∂28-Sep-88 1453 CL-Cleanup-mailer Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
C02839 00605 ∂28-Sep-88 1500 CL-Cleanup-mailer back....
C02840 00606 ∂28-Sep-88 1503 CL-Cleanup-mailer Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
C02843 00607 ∂28-Sep-88 1519 CL-Cleanup-mailer Re: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
C02845 00608 ∂28-Sep-88 1614 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
C02850 00609 ∂28-Sep-88 1619 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
C02860 00610 ∂28-Sep-88 1645 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02864 00611 ∂28-Sep-88 1656 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
C02867 00612 ∂28-Sep-88 1752 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 2)
C02872 00613 ∂28-Sep-88 1755 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C02875 00614 ∂28-Sep-88 1846 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
C02879 00615 ∂28-Sep-88 1939 CL-Cleanup-mailer on Splitting and Merging issues
C02881 00616 ∂29-Sep-88 0705 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION)
C02888 00617 ∂29-Sep-88 0727 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
C02890 00618 ∂29-Sep-88 1632 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02895 00619 ∂29-Sep-88 1733 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
C02897 00620 ∂30-Sep-88 1020 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
C02901 00621 ∂30-Sep-88 1419 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
C02912 00622 ∂30-Sep-88 1550 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
C02921 00623 ∂30-Sep-88 1554 CL-Cleanup-mailer Re: Issue: KILL-PACKAGE (Version 1)
C02923 00624 ∂30-Sep-88 1753 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
C02925 00625 ∂30-Sep-88 1804 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C02932 00626 ∂30-Sep-88 2135 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
C02941 00627 ∂30-Sep-88 2213 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
C02947 00628 ∂01-Oct-88 0156 CL-Cleanup-mailer Issue: DEFPACKAGE (version 4)
C02962 00629 ∂01-Oct-88 1338 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
C02967 00630 ∂01-Oct-88 1357 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 2)
C02980 00631 ∂01-Oct-88 1521 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
C02986 00632 ∂01-Oct-88 1548 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
C02990 00633 ∂01-Oct-88 1608 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 2)
C03003 00634 ∂01-Oct-88 1612 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
C03005 00635 ∂01-Oct-88 1619 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
C03007 00636 ∂01-Oct-88 1640 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
C03016 00637 ∂01-Oct-88 1709 CL-Cleanup-mailer Issue: ALIST-NIL (Version 3)
C03025 00638 ∂01-Oct-88 1748 CL-Cleanup-mailer Issue: NTH-VALUE (Version 2)
C03031 00639 ∂01-Oct-88 1749 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
C03035 00640 ∂01-Oct-88 1809 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
C03040 00641 ∂01-Oct-88 2055 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
C03043 00642 ∂01-Oct-88 2104 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
C03046 00643 ∂01-Oct-88 2130 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
C03049 00644 ∂02-Oct-88 0844 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
C03052 00645 ∂02-Oct-88 1135 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03072 00646 ∂02-Oct-88 1159 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
C03080 00647 ∂02-Oct-88 1223 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
C03082 00648 ∂02-Oct-88 1257 CL-Compiler-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03089 00649 ∂02-Oct-88 1308 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
C03092 00650 ∂02-Oct-88 1311 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03098 00651 ∂02-Oct-88 1333 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 5)
C03108 00652 ∂02-Oct-88 1346 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
C03110 00653 ∂02-Oct-88 1401 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03113 00654 ∂02-Oct-88 1426 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 2)
C03115 00655 ∂02-Oct-88 1434 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C03117 00656 ∂02-Oct-88 1446 CL-Cleanup-mailer Re: Issue: FUNCTION-DEFINITION (Version 1)
C03120 00657 ∂02-Oct-88 1509 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 2)
C03127 00658 ∂02-Oct-88 1608 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C03129 00659 ∂02-Oct-88 1617 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
C03139 00660 ∂02-Oct-88 1620 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 3)
C03148 00661 ∂02-Oct-88 1836 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
C03156 00662 ∂02-Oct-88 1847 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03168 00663 ∂03-Oct-88 0727 CL-Cleanup-mailer Re: Issue: TEST-NOT-IF-NOT (Version 1)
C03170 00664 ∂03-Oct-88 0958 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03175 00665 ∂03-Oct-88 1013 CL-Cleanup-mailer Re: Issue: TEST-NOT-IF-NOT (Version 1)
C03178 00666 ∂03-Oct-88 1014 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C03180 00667 ∂03-Oct-88 1025 CL-Cleanup-mailer Re: Issue: FORMAT-PRETTY-PRINT (version 5)
C03184 00668 ∂03-Oct-88 1035 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C03189 00669 ∂03-Oct-88 1038 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C03192 00670 ∂03-Oct-88 1309 CL-Cleanup-mailer Deprication, cleanup goals, performance
C03196 00671 ∂03-Oct-88 1323 CL-Cleanup-mailer Deprecation, cleanup goals, performance
C03199 00672 ∂03-Oct-88 1538 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 2)
C03202 00673 ∂03-Oct-88 1539 CL-Cleanup-mailer Re: Issue: KILL-PACKAGE (Version 2)
C03204 00674 ∂03-Oct-88 1720 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03209 00675 ∂03-Oct-88 1854 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C03212 00676 ∂03-Oct-88 1932 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
C03215 00677 ∂03-Oct-88 1954 CL-Compiler-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03222 00678 ∂03-Oct-88 1959 CL-Compiler-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03224 00679 ∂03-Oct-88 2042 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
C03227 00680 ∂03-Oct-88 2049 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
C03230 00681 ∂03-Oct-88 2102 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03236 00682 ∂04-Oct-88 0911 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C03240 00683 ∂04-Oct-88 1223 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
C03246 00684 ∂04-Oct-88 1303 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
C03248 00685 ∂04-Oct-88 1410 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 2)
C03250 00686 ∂04-Oct-88 1419 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 2)
C03252 00687 ∂04-Oct-88 1420 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 3)
C03258 00688 ∂04-Oct-88 1431 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
C03261 00689 ∂04-Oct-88 1434 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03265 00690 ∂04-Oct-88 1508 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 3)
C03279 00691 ∂04-Oct-88 1548 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
C03282 00692 ∂04-Oct-88 1557 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
C03286 00693 ∂05-Oct-88 0059 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03304 00694 ∂05-Oct-88 0110 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
C03307 00695 ∂05-Oct-88 0739 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
C03309 00696 ∂05-Oct-88 1102 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 2)
C03320 00697 ∂05-Oct-88 1105 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 2)
C03329 00698 ∂05-Oct-88 1121 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03336 00699 ∂05-Oct-88 1145 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
C03338 00700 ∂05-Oct-88 1151 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
C03340 00701 ∂05-Oct-88 1203 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
C03343 00702 ∂05-Oct-88 1207 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 2)
C03345 00703 ∂05-Oct-88 1221 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03349 00704 ∂05-Oct-88 1342 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 2)
C03352 00705 ∂05-Oct-88 1353 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 2)
C03355 00706 ∂05-Oct-88 1416 CL-Cleanup-mailer Issue: NTH-VALUE (Version 3)
C03361 00707 ∂05-Oct-88 1417 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03363 00708 ∂05-Oct-88 1417 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 3)
C03377 00709 ∂05-Oct-88 1510 CL-Cleanup-mailer Re: Potential Clean-Up Issues
C03386 00710 ∂05-Oct-88 1511 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
C03388 00711 ∂05-Oct-88 1543 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
C03392 00712 ∂05-Oct-88 1551 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 3)
C03394 00713 ∂05-Oct-88 1558 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03398 00714 ∂05-Oct-88 1612 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
C03400 00715 ∂05-Oct-88 1725 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 3)
C03407 00716 ∂05-Oct-88 1934 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
C03412 00717 ∂05-Oct-88 2032 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
C03420 00718 ∂05-Oct-88 2044 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 4)
C03422 00719 ∂05-Oct-88 2049 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 4)
C03425 00720 ∂05-Oct-88 2050 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03436 00721 ∂05-Oct-88 2154 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03442 00722 ∂05-Oct-88 2312 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
C03445 00723 ∂05-Oct-88 2330 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 5)
C03449 00724 ∂06-Oct-88 0019 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
C03453 00725 ∂06-Oct-88 0114 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 4)
C03458 00726 ∂06-Oct-88 0125 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03464 00727 ∂06-Oct-88 0132 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 3)
C03468 00728 ∂06-Oct-88 0207 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 8)
C03490 00729 ∂06-Oct-88 0827 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
C03492 00730 ∂06-Oct-88 1019 CL-Cleanup-mailer several hundred ugly things
C03495 00731 ∂06-Oct-88 1034 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
C03502 00732 ∂06-Oct-88 1213 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
C03504 00733 ∂06-Oct-88 1237 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
C03506 00734 ∂06-Oct-88 1258 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
C03510 00735 ∂06-Oct-88 1302 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
C03512 00736 ∂06-Oct-88 1315 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03515 00737 ∂06-Oct-88 1343 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03519 00738 ∂06-Oct-88 1350 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 3)
C03523 00739 ∂06-Oct-88 1530 CL-Cleanup-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
C03533 00740 ∂06-Oct-88 1532 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
C03561 00741 ∂06-Oct-88 1620 CL-Cleanup-mailer Issue: STREAM-INFO (Version 5)
C03565 00742 ∂06-Oct-88 1623 CL-Cleanup-mailer Re: Issue: STRUCTURE-INFO (Version 1)
C03568 00743 ∂06-Oct-88 1642 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 3
C03575 00744 ∂06-Oct-88 1649 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 5)
C03577 00745 ∂06-Oct-88 1755 CL-Cleanup-mailer Re: several hundred ugly things
C03584 00746 ∂06-Oct-88 1851 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
C03592 00747 ∂06-Oct-88 1852 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
C03601 00748 ∂06-Oct-88 1909 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
C03604 00749 ∂06-Oct-88 1958 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
C03608 00750 ∂06-Oct-88 1958 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
C03630 00751 ∂06-Oct-88 2002 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03632 00752 ∂06-Oct-88 2057 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
C03634 00753 ∂06-Oct-88 2115 CL-Cleanup-mailer Issue: DEFPACKAGE (version 5)
C03650 00754 ∂06-Oct-88 2118 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 4)
C03652 00755 ∂06-Oct-88 2124 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03655 00756 ∂06-Oct-88 2220 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
C03664 00757 ∂07-Oct-88 0017 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
C03678 00758 ∂07-Oct-88 0650 CL-Cleanup-mailer Re: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03681 00759 ∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
C03683 00760 ∂07-Oct-88 0836 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03688 00761 ∂07-Oct-88 0848 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03691 00762 ∂07-Oct-88 1020 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
C03694 00763 ∂07-Oct-88 1102 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
C03700 00764 ∂07-Oct-88 1106 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
C03702 00765 ∂07-Oct-88 1115 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 3
C03705 00766 ∂07-Oct-88 1144 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 3)
C03720 00767 ∂07-Oct-88 1212 CL-Cleanup-mailer several hundred ugly things
C03723 00768 ∂07-Oct-88 1222 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03726 00769 ∂07-Oct-88 1222 CL-Compiler-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03732 00770 ∂07-Oct-88 1305 CL-Cleanup-mailer PRINT-CIRCLE-STRUCTURE
C03740 00771 ∂07-Oct-88 1418 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C03747 00772 ∂07-Oct-88 1501 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
C03759 00773 ∂07-Oct-88 1528 CL-Cleanup-mailer Issue: DEFPACKAGE (version 5)
C03761 00774 ∂07-Oct-88 1556 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C03765 00775 ∂07-Oct-88 1608 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C03768 00776 ∂07-Oct-88 1616 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
C03774 00777 ∂07-Oct-88 1640 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
C03781 00778 ∂07-Oct-88 1643 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
C03783 00779 ∂07-Oct-88 1643 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 2)
C03792 00780 ∂07-Oct-88 1702 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
C03806 00781 ∂07-Oct-88 1732 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03809 00782 ∂07-Oct-88 1738 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
C03813 00783 ∂07-Oct-88 1743 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
C03818 00784 ∂07-Oct-88 1746 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
C03820 00785 ∂07-Oct-88 1752 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 4
C03822 00786 ∂07-Oct-88 1757 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
C03825 00787 ∂07-Oct-88 1802 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
C03827 00788 ∂07-Oct-88 1805 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03863 00789 ∂07-Oct-88 1812 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
C03868 00790 ∂07-Oct-88 2013 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03870 00791 ∂07-Oct-88 2018 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (version 1.1)
C03872 00792 ∂07-Oct-88 2019 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
C03877 00793 ∂07-Oct-88 2019 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03881 00794 ∂07-Oct-88 2028 CL-Cleanup-mailer Re: several hundred ugly things
C03884 00795 ∂07-Oct-88 2041 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
C03887 00796 ∂07-Oct-88 2018 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03892 00797 ∂07-Oct-88 2019 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 2)
C03894 00798 ∂07-Oct-88 2041 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
C03897 00799 ∂07-Oct-88 2041 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
C03902 00800 ∂07-Oct-88 2128 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
C03919 00801 ∂07-Oct-88 2149 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
C03921 00802 ∂07-Oct-88 2150 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
C03930 00803 ∂07-Oct-88 2150 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
C03932 00804 ∂07-Oct-88 2150 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
C03934 00805 ∂07-Oct-88 2150 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 4)
C03950 00806 ∂07-Oct-88 2304 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 5)
C03952 00807 ∂07-Oct-88 2343 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 7)
C03975 00808 ∂07-Oct-88 2351 CL-Cleanup-mailer Issue Status (finally!!)
C03994 ENDMK
C⊗;
∂19-Jun-88 2245 CL-Cleanup-mailer Re: Issue: COERCE-INCOMPLETE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Jun 88 22:45:51 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUN 88 22:44:31 PDT
Date: 19 Jun 88 22:44 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: COERCE-INCOMPLETE
In-reply-to: Masayuki Ida <ida%aoyama.cc.aoyama.junet@UTOKYO-RELAY.CSNET>'s
message of Mon, 13 Jun 88 11:07:16 JST
To: ida%aoyama.cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880619-224431-6041@Xerox>
A brief summary of our discussion of the issue COERCE-INCOMPLETE:
We think that COERCE is incomplete in some ways. However, we are not all happy
with the ways that you propose.
Making COERCE symmetric would probably be a bad idea, e.g., that it can coerce
from INTEGER to FLOAT and not from FLOAT to INTEGER is on purpose.
We think COERCE from integer to character is odd and non-portable and think it
perhaps should be removed from the standard.
COERCE from character to STRING is a good idea.
We are now puzzled by the inconsistency of (COERCE x 'STRING) vs (STRING x) and
want to reduce it.
We would like (COERCE x 'PATHNAME) to work like (PATHNAME x).
The reason that (COERCE symbol 'STRING) is difficult is that (COERCE 'NIL
'STRING) as a symbol could return "NIL", but (COERCE '() 'STRING) as the empty
list could return "".
FUNCTION-TYPE has extended COERCE to work for 'FUNCTION.
∂20-Jun-88 0729 CL-Cleanup-mailer KCL scoping bug?
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 20 Jun 88 07:27:35 PDT
Received: by CLI.COM (4.0/1); Mon, 20 Jun 88 09:22:45 CDT
Date: Mon, 20 Jun 88 09:22:45 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8806201422.AA07863@CLI.COM>
To: cl-cleanup@sail.stanford.edu
Cc: yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET,
Masinter.pa@Xerox.COM
Subject: KCL scoping bug?
Larry,
Here is all the correspondence on that particular issue from the kcl
mailing list.
From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 3 May 88 10:25:26 edt
To: ilan@ucbvax.Berkeley.EDU, vax135!froggy.ics.utexas.edu!boyer
Subject: KCL scoping bug?
Hi,
I'm not sure how to post stuff to the KCL board at the moment, so I'm
sending this to you. If you deem it worthwhile please post it
to the KCL mailing-list.
The following produces a scoping error in the interpreter (June 3, 87) -
the compiler handles the code correctly. (The example is lifted
directly from CLtL p. 155).
---------
>
(setq x 'x-dyn z 'z-dyn)Z-DYN
>
(load "nonsense.l")Loading nonsense.l
Finished loading nonsense.l
T
>
#'foo
(LAMBDA-BLOCK FOO (&REST ARGS) (PRINT ARGS) (LIST ARGS))
>#'nonsense
(LAMBDA-BLOCK NONSENSE (K X Z)
(FOO Z X)
(LET ((J (FOO K X)) (X (* K K)))
(DECLARE (INLINE FOO) (SPECIAL X Z))
(FOO X J Z)))
>(nonsense 1 2 3)
(3 2)
(1 2) ;;; <---- SHOULD BE (1 X-DYN)
(1 ((1 2)) Z-DYN) ;;; <---- SHOULD BE (1 ((1 X-DYN)) Z-DYN)
((1 ((1 2)) Z-DYN)) ;;; <---- SHOULD BE ((1 ((1 X-DYN)) Z-DYN))
>(compile 'nonsense)End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
NONSENSE
>
(nonsense 1 2 3)
(3 2)
(1 X-DYN)
(1 ((1 X-DYN)) Z-DYN)
((1 ((1 X-DYN)) Z-DYN))
------------------
--Ilan Caron ..!ucbvax!vax135!lcuxlj!ilan
From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 24 May 88 13:41:32 edt
Message-Id: <8805241741.AA29869@vax135.UUCP>
To: ilan@ucbvax.Berkeley.EDU, vax135!cli.com!kcl
Subject: KCL scoping bug?
A couple of weeks ago I posted what seemed to be a KCL interpreter
scoping bug using the example from CLtL p. 155.
Having seen no response to what seems to be a potential source
of major confusion, I'm reposting the bug - this time on a simpler
piece of code. The interpreter doesn't make a special reference
for Y in spite of the special declaration.
Please note that the bug only manifests itself when interpreted, the
compiler handles the situation correctly.
------------------
KCL (June 3, 1987)
------------------
Starts dribbling to x (1988/5/25, 2:29:20).
NIL
> #'foo
(LAMBDA-BLOCK FOO (X Y Z)
(LET ((X Y) (Y Z)) (DECLARE (SPECIAL Y Z)) (LIST X Y Z)))
>(setq x 'dyn-x y 'dyn-y z 'dyn-z)
DYN-Z
>(foo 'lex-x 'lex-y 'lex-z)
(LEX-Y DYN-Z DYN-Z) ;;; <---- should be (DYN-Y ...)
> (compile 'foo)
; (DEFUN FOO ...) is being compiled.
;; Warning: The variable X is not used.
;; Warning: The variable Y is not used.
;; Warning: The variable Z is not used.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
FOO
>(foo 'lex-x 'lex-y 'lex-z)
(DYN-Y DYN-Z DYN-Z) ;;; <---- this is correct
>
---------
--ilan caron
Date: Thu, 26 May 88 10:10:26 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@relay.cs.net>
To: kcl@cli.com
Subject: Re: KCL scoping bug?
Here's the story.
I noticed long time ago that there's an inconsistency as you
posted. However, at that time I did not know which interpretation
is correct. So, I decided to leave the inconsistency until
someone (x3j13, perhaps) clarifies which is correct. I still do not
know which is correct. It's easy to solve the inconsistency.
Is there any general consensus on this matter?
If most people agree that the compiler is correct and the interpreter
is wrong, I'm happy to fix the bug immediately.
-- Taiichi
Received: by CLI.COM (4.0/1); Tue, 31 May 88 12:41:47 CDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA01603; Tue, 31 May 88 09:18:42 PDT
From: vax135!melmac!ilan@ucbvax.Berkeley.EDU
Date: Tue, 31 May 88 12:13:03 edt
Message-Id: <8805311613.AA03145@vax135.UUCP>
To: vax135!cli.com!kcl
Subject: Re: KCL scoping bug?
The example and explanation on p. 155 CLtL makes it pretty
clear that the compiler is correct, (i.e. that the special
declaration also applies to references within the initforms
of a LET) - in particular, The Book says: "The reference
to X in the second call to FOO is also a special reference".
------------------------------------------------------------
For those interested, the relevant nonsensical code is:
(defun nonsense (k x z)
(foo z x)
(let
(
(j (foo k x)) ;;; <--- the problematic reference to X
(x (* k k))
)
(declare (inline foo) (special x z))
(foo x j z)
)
)
--ilan caron
∂20-Jun-88 0748 CL-Cleanup-mailer Common Lisp Semantics for Function Call
Received: from CLI.COM by SAIL.Stanford.EDU with TCP; 20 Jun 88 07:48:10 PDT
Received: by CLI.COM (4.0/1); Mon, 20 Jun 88 09:43:23 CDT
Date: Mon, 20 Jun 88 09:43:23 CDT
From: Robert S. Boyer <boyer@CLI.COM>
Message-Id: <8806201443.AA08049@CLI.COM>
To: cl-cleanup@sail.stanford.edu
Cc: yuasa%tutics.tut.junet%utokyo-relay.csnet@RELAY.CS.NET,
Masinter.pa@Xerox.COM, wfs@CLI.COM
Subject: Common Lisp Semantics for Function Call
In the case of an ordinary function call, does Common Lisp specify
whether the symbol-function is grabbed before or after the args are
evaluated? Symbolics and KCL do it "before" when interpreting and
"after" when running compiled code. This question was previously
reported to the Common Lisp mailing list, by Bill Schelter around
December 87 I think, but I saw no response.
It seems to me that the natural solution is to go "before". This
(a) provides an extension of the left-to-right-order of evaluation
that is part of Common Lisp (even if it is not in the manual), and
(b) is consistent with the idea that you need, when interpreting,
to look at the definition of the car of the form to decide
whether it is a macro or not.
Below is an illustration of the problem of "before" vs. "after",
in KCL.
>(defun foo ()
(setf (symbol-function 'bar) #'(lambda (x) (print 'old)))
(bar (setf (symbol-function 'bar) #'(lambda (x) (print 'new)))))
FOO
>(foo)
OLD
OLD
>(foo)
OLD
OLD
>(foo)
OLD
OLD
>(compile 'foo)
FOO
>(foo)
NEW
NEW
>(foo)
NEW
NEW
>(foo)
NEW
NEW
; It is, of course, unnecessary to observe that such coding is
; inelegant, even repulsive.
∂20-Jun-88 0921 CL-Cleanup-mailer Issue: COERCE-FROM-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 09:21:27 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 421917; Mon 20-Jun-88 12:20:05 EDT
Date: Mon, 20 Jun 88 12:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COERCE-FROM-TYPE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620121941.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: COERCE-FROM-TYPE
References: COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category: ADDITION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
COERCE is difficult to extend because ambiguities arise about the
source type of the coercion.
For example, should (COERCE NIL 'STRING) return "" or "NIL".
The choice would be arbitrary unless you knew whether NIL was being
viewed as an empty list or a symbol.
Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
implementations -- or it might return "A", depending on whether the
result of char-code was viewed as a number or more specifically as
a character code.
Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):
Add an extra optional argument to COERCE which specifies the type
from which the coercion is to be done. The new syntax would be:
COERCE object to &optional (from (TYPE-OF object))
Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.
Rationale:
This leaves room for a subsequent proposal to extend COERCE in
interesting ways. For example, extensions such as the following
might be considered:
(COERCE NIL 'STRING 'LIST) => ""
(COERCE NIL 'STRING 'SYMBOL) => "NIL"
A new type CHAR-CODE might even be introduced as
(DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
so that COERCE could handle cases like:
(EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
(FORMAT NIL "~D" (CHAR-CODE #\A))) => T
(COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"
Such specific proposals are deliberately not part of this proposal
in order to separate the general purpose mechanism from the more
specific details.
Current Practice:
Probably no one implements the proposed behavior at this time.
Cost to Implementors:
The more optimization a compiler does (or might do) of COERCE, the more
work might be necessary. In general, however, the changes would probably
not involve a major amount of work.
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
Various proposals to extend COERCE would probably not pass because
not everyone can agree on how to view the type of the first argument
when more than one type is possible.
Benefits:
More (if not all) kinds of coercions in the language would be able
to go through COERCE. Documentation and ease of use would be simplified.
Aesthetics:
A part of the language which is currently in somewhat of a disarray
would become more organized, making it simpler to explain and easier
to learn.
Discussion:
Pitman wrote and supports COERCE-FROM-TYPE:NEW-ARGUMENT.
Pitman is also studying similar generalizations of EQUAL and COPY that
might address the numerous problems with those operators.
The main obstacle to extending COERCE in the past has been that when an
object could be viewed as more than one type, confusion might result if
people did not agree on the view in use. Since if this proposal passed
there is a way to specify the view type of the object going in, it might
then be worth considering whether COERCE should be made generic and
whether a standard protocol for extending it could be defined.
∂20-Jun-88 1149 CL-Cleanup-mailer comments on draft proposals
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jun 88 11:49:49 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA21981; Mon, 20 Jun 88 12:48:31 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806201848.AA21981@cs.utah.edu>
Date: Mon, 20 Jun 88 12:48:30 MDT
Subject: comments on draft proposals
To: cl-cleanup@sail.stanford.edu
EQUAL-STRUCTURE: My favorite alternative is CHANGE-EQUALP. I have found
the current definition of EQUALP to be pretty useless. I actually think
that the most useful behavior would be to have EQUAL descend only list
structures and compare everything else with EQL, and have EQUALP descend
arrays and structures as well as lists while making it consider characters
of different case and numbers of different types distinct.
DEFPACKAGE: I like this proposal. About the only thing I would change
would be making the options that only use the names of the symbols
(everything but :IMPORT and :SHADOWING-IMPORT) take strings as well.
I would also like to see some clarification of the order in which things
happen: do the clauses get processed in the order they appear, or in
"Put In Seven Extremely Random User Interface commands" order, or in
some other order? The compiler cleanup group would be willing to put
forward a proposal to remove the magic status of the N random package
forms, but I think the DEFPACKAGE proposal can stand on its own.
DECLARATION-SCOPE: Seems OK to me. It is at least more understandable
than the current language in CLtL.
-Sandra
-------
∂20-Jun-88 1311 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 13:11:35 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422133; Mon 20-Jun-88 16:10:25 EDT
Date: Mon, 20 Jun 88 16:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620160959.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used in place of a
function as an argument to operators which take functional arguments,
the coercion of that non-function to a function is delayed as long as
possible. That is, it is as if the result of calling
#'(LAMBDA (NON-FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(APPLY NON-FUNCTION ARGUMENTS)))
on the non-functional argument were passed instead.
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used in place of a
function as an argument to operators which take functional arguments,
the coercion of that non-function to a function is done immediately.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used in place of a
function as an argument to operators which take functional arguments,
the coercion of that non-function to a function must be done immediately
if the functional argument is to be used only internally to the function
(eg, SORT or MAPCAR) but is delayed as long as possible otherwise. (eg,
SET-MACRO-CHARACTER). That is, it is as if the result of calling
#'(LAMBDA (NON-FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(APPLY NON-FUNCTION ARGUMENTS)))
on the non-functional argument were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
∂20-Jun-88 1312 CL-Cleanup-mailer Issue: ALIST-NIL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 13:12:48 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 422136; 20 Jun 88 16:11:32 EDT
Date: Mon, 20 Jun 88 16:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620161106.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Character-Type-Mappings: (1 0 (NIL 0) (NIL :ITALIC NIL) "CPTFONTI")
Fonts: CPTFONT, CPTFONTI
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
NIL is permitted to be an element of an a-list but nothing useful
can be done with such an element.
Proposal (ε1issue-nameε0:ε1proposal-nameε0):
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
No motivation in CLtL is given for NIL being allowed in an a-list.
The description of a-lists seem needlessly complicated by this feature.
FIND (with a :KEY of #'CAR) and ASSOC (with no key) are almost identical
except for their treatment of this issue. If no one makes significant
use of the feature, it would be better to be able to simplify the
relationship between these functions.
Current Practice:
All valid implementations allow NIL.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which the author is able to guess this
feature might be used:
#1: A user might want a leading NIL on an a-list so that if the list
were empty, there'd still be a tail to which cells could be attached
in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that this is more
clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) ENTRY) ;Something unique
(SETF (CAR ALIST) ENTRY)))
Cost of Non-Adoption:
There only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
Simplified documentation.
Aesthetics:
This change would simplify the language.
Discussion:
Pitman submitted this proposal after looking at the write-up of
a-lists in the new standard. The description seems needlessly
cluttered by this unmotivated and he felt that either a motivation
for this feature should be cited and defended or the feature should
go away. The degree to which he believes in this feature will be
determined by any claims made by others in ensuing discussion.
Some people might consider this change gratuitous.
∂20-Jun-88 1316 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 13:16:01 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422142; Mon 20-Jun-88 16:14:36 EDT
Date: Mon, 20 Jun 88 16:14 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620161405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: TRACE-ERROR
References: TRACE (p440), UNTRACE (p440)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
TRACE does not signal an error when given invalid options in
some implementations. For example, more than one implementation
might an extended syntax such as:
(TRACE (FOO {key value}*))
but they might still vary as to what options they provided.
In some such implementations, GET might be used to detect the
options the implementation is interested in, rather than iterating
down the list trying to determine which options really apply.
As such, if
(TRACE (FOO :WHEREIN BAR))
is done by someone used to an implementation that allowed a :WHEREIN
keyword, an implementation might simply ignore the :WHEREIN keyword.
It may not be until a computation is well underway that the ignored
(possibly mis-named or mis-spelled) keyword is detected. Backing up
to retry the trace once the problem is detected may be expensive and
frustrating.
Proposal (TRACE-ERROR:REQUIRE-SIGNAL):
Permit the use of non-standard syntax, but require that TRACE and UNTRACE
do careful syntax checking and signal an error if any unknown options
or syntax are used.
Test Case:
(TRACE (FOO :WHEREIN BAR))
might mean any of a variety of things, but would not be permitted to just
trace FOO and silently ignore the :WHEREIN option as if it had not been
specified.
Rationale:
TRACE is an environmental interface which varies greatly between
implementations. Implementors moving frequently between implementations
can get confused about which implementation they are dealing with and
make mistakes that were trivially avoidable by simple error checking at
the proper time.
Some errors of this kind are not eliminated by this proposal. For example,
two implementations may use the same syntax and/or option in different ways.
However, in many cases where implementations offer extensions, the namings
are not done in a vacuum and they frequently try to agree on naming -- so
this problem is more rare than random chance might suggest. In any case,
this proposal clearly reduces risk of error even if it does not eliminate it.
Current Practice:
Implementations are currently permitted to ignore spurious TRACE
options/syntax because of TRACE's weak contract, and many do.
Cost to Implementors:
Trivial error checking would have to be added to TRACE and UNTRACE.
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
Some interactive problems would continue to be likely to occur periodically.
Benefits:
A possible source of interactive debugging error is removed.
Aesthetics:
Users will feel a little safer.
Discussion:
Pitman wrote and supports TRACE-ERROR:REQUIRE-SIGNAL.
This issue came up while debugging Macsyma on a system which quietly
ignored what Pitman felt were TRACE options that should either be used
or complained about.
∂20-Jun-88 1411 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 14:11:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422182; Mon 20-Jun-88 17:10:16 EDT
Date: Mon, 20 Jun 88 17:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880620170950.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
References: DECODE-UNIVERSAL-TIME (p445)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The description of DECODE-UNIVERSAL-TIME does not say what happens with
TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
its behavior differs depending on whether a time zone is explicitly passed,
some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
likewise.
Even if all implementations did the same thing, it should still be clarified
whether an implementation were permitted to return dsp=NIL tz=n rather than
dsp=T tz=n+1 for time zones in which daylight savings time was believed to
be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
daylight-savings-time-p means "daylight savings time is in effect" or
just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
daylight savings information if a timezone is explicitly specified.
Rationale:
This makes things consistent with ENCODE-UNIVERSAL-TIME.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:UNLIKE-ENCODE):
Specify that, unlike ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME treats
daylight savings information the same regardless of whether a time zone
argument is explicitly or not.
Rationale:
Although inconsistent with ENCODE-UNIVERSAL-TIME, this seems
to be what was intended.
[Maybe someone can suggest a better motivation? -kmp]
Test Case:
;; ### Kludge: This test case relies on time zone not changing in real
;; ### time, in blatant defiance of warning in note at bottom
;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
(RECENTLY (GET-UNIVERSAL-TIME))
(A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
(B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
(LIST A B (EQUAL A B)))
Current Practice:
Symbolics Genera and Symbolics Cloe return ((T 5) (NIL 5) NIL) in EDT.
Cost to Implementors:
The cost of changing this should be trivial.
Cost to Users:
This feature is already not well-defined since no portable program can rely
on the current behavior, so the cost is effectively zero.
Cost of Non-Adoption:
The time primitives are considerably less useful if this point is not
clearly spelled out.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Anything that improves the intelligibility of language primitives improves
language aesthetics.
Discussion:
Pitman wrote this proposal after running into this problem while trying
to port Macsyma between different Common Lisp implementations. He doesn't
have a strong preference on which proposal should be adopted, but thinks
this issue should be nailed down.
∂20-Jun-88 1418 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jun 88 14:18:37 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 422192; Mon 20-Jun-88 17:17:22 EDT
Date: Mon, 20 Jun 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
References: <880620170950.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880620171657.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
That last subject line should have been DECODE-UNIVERSAL-TIME-DAYLIGHT
to match what's in the proposal. Sorry.
∂20-Jun-88 1546 CL-Cleanup-mailer STEP-ENVIRONMENT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Jun 88 15:46:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA29826; Mon, 20 Jun 88 16:44:53 MDT
From: sandra@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8806202244.AA29826@cs.utah.edu>
Date: Mon, 20 Jun 88 16:44:51 MDT
Subject: STEP-ENVIRONMENT, version 3
To: cl-cleanup@sail.stanford.edu
As promised, here is a revised version of the STEP-ENVIRONMENT proposal.
I have removed the part of the proposal that would make STEP a special
form instead of a macro.
-Sandra
Issue: STEP-ENVIRONMENT
References: STEP (CLtL p.441)
TIME (CLtL p.441)
Category: CLARIFICATION/CHANGE
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 10-Jun-88, Masinter (add discussion)
Version 3, 20-Jun-88, Loosemore (not a special form)
Problem description:
CLtL does not specify in what lexical environment the form given to STEP
is evaluated. Some people think it's supposed to be evaluated in the
null environment, others think it is supposed to be evaluated in the
current environment, the one in which the STEP form was evaluated.
The same considerations apply to TIME.
Proposal (STEP-ENVIRONMENT:CURRENT):
1. Clarify that STEP and TIME evaluate the form in the current environment.
2. Clarify that calls to both STEP and TIME may be compiled, but that
in the case of STEP, it is acceptable for an implementation to
interactively step through only those parts of the evaluation that are
interpreted.
Test Cases/Examples:
;Assuming X is not a special variable
(setq x 1)
(let ((x 2))
(step (print x)))
This should print and return 2, not 1, when interpreted.
Rationale:
1. It is more useful for the lexical environment to pass transparently
through STEP and TIME than to reset to the null environment.
2. Although STEP is primarily a debugging tool, there is no reason to
prevent it from being compiled correctly.
Current practice:
Vax Lisp behaves as proposed. Symbolics Common Lisp treats STEP as a special
form and does not allow it to be compiled.
Cost to Implementors:
Minimal.
Cost to Users:
None.
Cost of non-adoption:
These debugging tools will continue to have vague specifications.
Benefits:
Slightly more preicse specification of Common Lisp.
Esthetics:
Slightly improved.
Discussion:
There was some discussion of separating this out into two separate
proposals, but it didn't seem useful.
Eric Benson contributed the definition of TIME in Lucid Common Lisp:
(defmacro time (form)
`(time-internal #'(lambda () ,form)))
The function TIME-INTERNAL looks something like:
(defun time-internal (thunk)
(let ((before-time (get-time-state)))
(unwind-protect
(funcall thunk)
(print-time-information before-time (get-time-state)))))
The definition of STEP is similar. This is just to show that it is
easy to get the right lexical environment even though TIME and STEP
are macros.
VaxLisp expands STEP into something like:
(defmacro step (form)
`(let ((*eval-hook* #'step-command-loop))
,form))
-------
∂20-Jun-88 1842 CL-Cleanup-mailer Issue: STEP-ENVIRONMENT, version 3
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 20 Jun 88 18:42:35 PDT
Date: 20 Jun 88 21:20:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Issue: STEP-ENVIRONMENT, version 3
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
This looks pretty good--we really want to minimize the number of special
forms if at all possible.
---Walter
------
∂21-Jun-88 0003 CL-Cleanup-mailer
Received: from research.att.com (ATT.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jun 88 00:03:28 PDT
From: frodo@research.att.com
Date: Tue, 21 Jun 88 03:00:14 EDT
To: cl-cleanup@sail.stanford.edu
I have received your message of Mon Jun 20 04:00:28 1988 correctly.
This message is being sent by my automatic mail answering program.
(Really, no sh....)
I'm sailing to Cape Cod on board Nimble.
I will return Friday June 24, 1988.
If you are sending me mail because you need help with a system related
problem and are you are in need of help immediately, perhaps you should
contact someone else.
Ted J. Kowalski
(If you send me another message, this message will not be repeated)
∂21-Jun-88 1739 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88 17:39:38 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 17:39:43 PDT
Received: from blacksox.lucid.com by edsel id AA21953g; Tue, 21 Jun 88 14:13:19 PDT
Received: by blacksox id AA00406g; Tue, 21 Jun 88 14:12:17 pdt
Date: Tue, 21 Jun 88 14:12:17 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806212112.AA00406@blacksox.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Mon, 20 Jun 88 16:14 EDT <880620161405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)
It seems to me that this is beyond the scope of the cleanup committee
or even the standardization effort. What you are describing is a bug
in a particular implementation of TRACE. It is a bug because it
reduces the usability of TRACE, not because that version of TRACE does
not conform to some present or future Common Lisp standard. Send a
bug report to your Lisp supplier.
P.S. As it happens, I think that supplier is Lucid! I believe that
our TRACE implementation accepts the :WHEREIN keyword but does not
implement its functionality. As it turns out, I think we can now
implement :WHEREIN easily, but everyone forgot about it! Send in a
bug report and it will go on the queue of things to do. (I could
submit a bug report myself, but customers get higher priority.)
∂21-Jun-88 1740 CL-Cleanup-mailer STEP-ENVIRONMENT, version 3
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 21 Jun 88 17:40:22 PDT
Received: by labrea.stanford.edu; Tue, 21 Jun 88 17:40:26 PDT
Received: from blacksox.lucid.com by edsel id AA21993g; Tue, 21 Jun 88 14:17:18 PDT
Received: by blacksox id AA00409g; Tue, 21 Jun 88 14:16:19 pdt
Date: Tue, 21 Jun 88 14:16:19 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8806212116.AA00409@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 20 Jun 88 16:44:51 MDT <8806202244.AA29826@cs.utah.edu>
Subject: STEP-ENVIRONMENT, version 3
Add to Current Practice: Lucid Common Lisp behaves as proposed.
∂22-Jun-88 1004 CL-Cleanup-mailer Issue: TRACE-ERROR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88 10:04:05 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423231; Wed 22-Jun-88 13:03:12 EDT
Date: Wed, 22 Jun 88 13:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TRACE-ERROR (Version 1)
To: edsel!eb@labrea.stanford.edu
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8806212112.AA00406@blacksox.lucid.com>
Message-ID: <880622130258.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Tue, 21 Jun 88 14:12:17 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
It seems to me that this is beyond the scope of the cleanup committee
or even the standardization effort. What you are describing is a bug
in a particular implementation of TRACE.
Not necessarily if the documentation doesn't say it's a bug. Some vendors
prefer not to change anything that the standard doesn't require them to change.
Also, the time between releases may be very long. And, as far as I can see,
there's no good reason I should ever find myself inconvenienced by this problem.
It is a bug because it reduces the usability of TRACE,
Few vendors use this criterion in general for determining what's a bug
and what's not.
not because that version of TRACE does not conform to some present or
future Common Lisp standard.
Certainly not if we don't agree to discuss it in this forum, but that's
a bit self-defeatist.
Send a bug report to your Lisp supplier.
But it's not guaranteed to help since I have no leverage.
I (wearing my third-party application developer hat) can afford to
discriminate against a CL because it doesn't do floating point or bignums
right, or because it doesn't implement lexical closures, but if it reaches
and interesting target market and it doesn't do TRACE right, I'm probably
going to be stuck using it. Some vendors want to implement just the bare
minimum and appeal to the full force of the "is an error" rule wherever
possible. I think that where reasonable we should raise the least common
denominator, and I think a reasonable place to start is in places that
users (eg, me, in this case) report that there's been a problem.
In this particular case, any reasonable vendor is probably going to give
in to my demands, but this bug is an easy mistake to make and there's no
reason not to put the feature I'm asking for in the standard if only to
remind all vendors to get the feature into release 1 of their product.
P.S. As it happens, I think that supplier is Lucid! ...
I'm pretty sure it was not.
I believe that our TRACE implementation accepts the :WHEREIN keyword
but does not implement its functionality.
[Actually, I just pulled :WHEREIN out of a hat. I don't remember the real
keyword, but I know I never use :WHEREIN. Maybe it was :BREAK...] Anyway,
I'm inclined to believe this would be acceptable as long as TRACE does
typeout saying that it was not using the keyword. Anything that tells the
user what's going on.
∂22-Jun-88 1254 CL-Cleanup-mailer Issue: STREAM-CLASS-ACCESS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88 12:54:25 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423341; Wed 22-Jun-88 15:54:01 EDT
Date: Wed, 22 Jun 88 15:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-CLASS-ACCESS (version 1)
To: vanroggen%aitg.decnet@Hudson.DEC.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 17 Jun 88 20:34 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880622155347.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
I have this issue filed as STREAM-CLASS-ACCESS. You called it just
STREAM-ACCESS. It would be nice if we could stick to just one name so
that I and others who try to keep this stuff usefully archived don't get
the archive split uselessly into two pieces.
The editorial committee should see to it that it's clear that these
types have to do with `structure' rather than `intent' of the resulting
streams. For example, if you broadcast to two string streams, you have a
stream of type BROADCAST-STREAM, not (necessarily) a string of type
STRING-STREAM, etc.
In any case, the write-up looks generally quite good as it stands and
the proposal has my support.
∂22-Jun-88 1508 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jun 88 15:08:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423409; Wed 22-Jun-88 18:08:02 EDT
Date: Wed, 22 Jun 88 18:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Proposal (LAMBDA-FORM:NEW-SPECIAL-FORM):
Add a new special form LAMBDA, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
except that the macro expansion might not be available in all
implementations.
Rationale:
This is a slightly incompatible extension which ``codifies current
practice'' in that it makes a commonly defined feature available
as a standard part of the language. The idea of making it a special
form would be that some people would prefer to treat (LAMBDA ...)
as more primitive than #'(LAMBDA ...).
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
; The following result is required under NEW-MACRO
; and is possible under NEW-SPECIAL-FORM
=> (FUNCTION (LAMBDA (X) (+ X Y)))
; The following result is prohibited under NEW-MACRO
; and is permitted but not required under NEW-SPECIAL-FORM.
=> (LAMBDA (X) (+ X Y))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. (Actually,
CLtL technically does allow it, but arguably only by technicality.)
Cost to Implementors:
NEW-MACRO is trivial to add.
NEW-SPECIAL form might require more work in some implementations, but
probably not a lot more.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
Improved aesthetics.
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe strongly that (LAMBDA ...) looks a lot better
than #'(LAMBDA ...). Certainly it takes up fewer characters, and
(LAMBDA ...) is a notable offender in code needing to be split onto
multiple lines, so every little bit helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
∂22-Jun-88 2258 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88 22:58:22 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 22:58:11 PDT
Date: 22 Jun 88 22:46 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 16:09 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-225811-3055@Xerox>
This is the right idea, but "at late as possible" is probably too vague to
satisfy folks.
I think the idea is that supplying x as a functional argument to remove-if,
mapc, etc. should work identically to supplying #'(lambda (&rest arguments)
(apply (if (functionp x) x (symbol-function x)) arguments))
∂22-Jun-88 2306 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88 23:06:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:06:16 PDT
Date: 22 Jun 88 22:56 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ALIST-NIL (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 16:11 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-230616-3064@Xerox>
of all of the odd little confusing corners of CL, this seems like one of the
least important to clean up. I would imagine the intent was more along the
lines of your #2; and that putting NIL there seems simpler than putting some
otherwise useless CONS. Besides, putting the NIL there also makes it clear where
the "dummy" entries are, allowing for a quick (remove nil alist).
So, I'm agin it.
∂22-Jun-88 2317 CL-Cleanup-mailer Re: Issue: TRACE-ERROR (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88 23:17:32 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:16:36 PDT
Date: 22 Jun 88 23:06 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TRACE-ERROR (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 16:14 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-231636-3071@Xerox>
I would like to separate out, if possible, the requirement for conformance --
what it is you have to have to say that you have ANSI Common Lisp -- and the
strong recommendations the standard might make for having an acceptable
environment. This issue is in many ways like IF-BODY; it attempts to put some
constraints on things that implementations do that aren't part of the standard
anyway.
I don't know for sure that there is precedent, but I vaguely remember some
similar wording in other standards documents. I'd like to see the only
"standard" for ED, TRACE, BREAK and the other "environment" features be that
they exist in the Lisp package and that the implementations document what they
do; secondly, we can strongly *recommend* (maybe in the notes) that TRACE do
error checking and that DRIBBLE change the current *terminal-io* rather than
work with an embedded top-level loop.
We certainly gutted DRIBBLE, I don't know why we should turn around and tighten
up TRACE.
∂22-Jun-88 2338 CL-Cleanup-mailer Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Jun 88 23:38:39 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 JUN 88 23:35:08 PDT
Date: 22 Jun 88 23:24 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 17:16 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880622-233508-3081@Xerox>
I think it takes more deduction than most of our readers are willing to expend
to figure out how to interpret various return values for your test case.
∂23-Jun-88 0153 CL-Cleanup-mailer &key in defstruct :constructor arglists
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 23 Jun 88 01:45:32 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA02079; Thu, 23 Jun 88 01:44:08 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA29442; Wed, 22 Jun 88 17:27:29 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA26402; Wed, 22 Jun 88 17:34:18 PDT
Message-Id: <8806230034.AA26402@denali.sun.com>
To: cl-cleanup@sail.stanford.edu
Cc: cl-cleanup-request@sail.stanford.edu
Cc: peck@Sun.COM
Subject: &key in defstruct :constructor arglists
Date: Wed, 22 Jun 88 17:34:16 -0700
From: peck@Sun.COM
Is there a really good reason why the arglists for :constructor functions
may *not* include a mix of keyword and non-keyword specifiers??
CLtL, page 316:
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
I would like to do this:
(defstruct (foo (:constructor create-foo (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
But CLtL encourages me do something ugly like this:
(defstruct (foo (:constructor create-foo% (a b c d &aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(defun create-foo (a &optional b (c 'sea) &key (d 2))
(create-foo% a b c d))
Even so, the handling of foo-b is incorrect if create-foo is called with
only 1 argument. Must a user hand code all the supplied-p forms to do this?
CLtL: "The actions taken in the B and E cases were carefully chosen to
allow the user to specify all possible behaviors."
The intent is clearly to make this *easier* for programmers...
Is the code to handle &key really any different than for &optional?
Biggest impact i can see here is that we might lose the cuteness of
strictly "By Order of Arguments" --> "BOA-constructor".
PS to: cl-cleanup-request@sail.stanford.edu
please add me to this list: peck@sun.com
∂23-Jun-88 0725 CL-Cleanup-mailer Re: Issue: TRACE-ERROR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 07:25:18 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423614; Thu 23-Jun-88 10:24:49 EDT
Date: Thu, 23 Jun 88 10:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TRACE-ERROR (Version 1)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-231636-3071@Xerox>
Message-ID: <880623102431.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 22 Jun 88 23:06 PDT
From: masinter.pa@Xerox.COM
I would like to separate out, if possible, the requirement for
conformance -- what it is you have to have to say that you have
ANSI Common Lisp -- and the strong recommendations the standard
might make for having an acceptable environment.
I'm completely baffled by why anyone thinks this has anything whatsoever
to do with conformance. Conformance has to do with adherence to what is
written. I'm suggesting we write something different. Whether people
conform or not will be judged against what we write and is, indeed,
something beyond our jurisdiction.
This issue is in many ways like IF-BODY; it attempts to put some
constraints on things that implementations do that aren't part of
the standard anyway.
There are things that are intended to be left open and things that
are not. We have to separate them out. I am asserting that the right
to ignore a user's TRACE specification without a hint that that's what
you're doing is something we don't want to leave open, even if we leave
open what kinds of TRACE extensions we allow. This is no different than
allowing people to extend COERCE or OPEN or SUBTYPEP, but requiring
specifying that COERCE must signal an error if it can't do the coercion
or that OPEN must still return a stream even if the keywords are
non-standard or how TYPEP passes back information about the fact that
it couldn't do its job correctly.
I don't know for sure that there is precedent, but I vaguely
remember some similar wording in other standards documents. I'd like
to see the only "standard" for ED, TRACE, BREAK and the other
"environment" features be that they exist in the Lisp package and
that the implementations document what they do;
I'd be almost ammenable to this except that I'd want to specify that if
they do nothing they must either return some CL-specified value or
else do typeout informing the user that they did nothing.
For example, on the 3600, ED communicates with and/or spins off a new
process which will run the editor. It therefore returns before it has
`done anything'. On the 3600, you have a bar at the bottom of the screen
that tells you that the machine is still busy, so this isn't too baffling.
If I were on a machine that did not have a status line at the bottom of
the screen and called ED only to see it return, I might not know if it
was still doing something in background and might not know how to decide
when to stop waiting.
secondly, we can strongly *recommend* (maybe in the notes) that TRACE do
error checking
This would be ok, but since no one has advanced a reason why TRACE should
not always do error checking, this is pretty wimpy.
and that DRIBBLE change the current *terminal-io* rather than
work with an embedded top-level loop.
People have advanced valid reasons for this not to happen. It's interesting
that you pick these examples because you seem to intend me to be able to
send a bug report to an implementation which doesn't follow the recommendation
saying "gosh, i wish it did" and yet I hope you're not trying to incite
Lispm users to riot by inserting a recommendation about DRIBBLE which is
non-binding but which has been shown not to be generally agreed upon by the
technical community.
I personally think there is no place for notes in the standard. There
bindingness on conformity (or lack thereof) is just too confusing.
We certainly gutted DRIBBLE, I don't know why we should turn around and tighten
up TRACE.
Not so. We didn't gut DRIBBLE, we acknowledged the status quo (a status quo
which was supported by the existing vague wording). Making any change would
have forced some implementation to make an incompatible change. On the other
hand, the proposed change to TRACE is not interestingly incompatible. The two
issues are not at all in the same class as I see it.
∂23-Jun-88 0733 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 07:33:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423620; Thu 23-Jun-88 10:33:19 EDT
Date: Thu, 23 Jun 88 10:33 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: ALIST-NIL (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-230616-3064@Xerox>
Message-ID: <880623103303.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 22 Jun 88 22:56 PDT
From: masinter.pa@Xerox.COM
of all of the odd little confusing corners of CL, this seems like one of the
least important to clean up.
i don't know what your criterion for importance is. there was a lot of mail
a while back that exposed widespread confusion about whether even arbitrary
symbols could occur in an alist. this was traced to confusion over the need
to mention atoms in one paragraph forced by the mention elsewhere of nil as
a possible alist element.
i continue to believe that the proper metric of importance is the set of things
which people think important enough to bother mentioning. even if there seem
to be a thousand things of similar kind in the language, the fact that the
complainants do not mention the other 999 is an appropriate way of rank ordering
the one against the other 999.
in this case, confusion over what can go in alists was already on my list of
problems from macsyma days. it came up again on the common-lisp mailing list.
and it came up again when i was looking at the standard this time around.
i consider this reason enough for the issue to go to committee vote unless
someone can advance a sound technical argument as to why nils should be allowed.
I would imagine the intent was more along the lines of your #2; and that
putting NIL there seems simpler than putting some otherwise useless CONS.
on the other hand, i have never seen this done in practice so it may have been
useless optimization.
Besides, putting the NIL there also makes it clear where
the "dummy" entries are, allowing for a quick (remove nil alist).
well, if your only purpose was to do a remove later, you could often just
put :DELETED there and be sure to clean up the alist when you were done,
or else just do the real splicing as you went.
So, I'm agin it.
i'll add your no vote on the next revision.
∂23-Jun-88 0738 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 07:38:32 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423624; Thu 23-Jun-88 10:37:51 EDT
Date: Thu, 23 Jun 88 10:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 1)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622-225811-3055@Xerox>
Message-ID: <880623103735.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 22 Jun 88 22:46 PDT
From: masinter.pa@Xerox.COM
This is the right idea, but "at late as possible" is probably too vague to
satisfy folks.
Sigh. You're probably right.
I think the idea is that supplying x as a functional argument to remove-if,
mapc, etc. should work identically to supplying #'(lambda (&rest arguments)
(apply (if (functionp x) x (symbol-function x)) arguments))
Since I plan to submit a cleanup item to re-allow LAMBDA expressions as coerceable
to functions, i would appreciate it if we could avoid any wording that got us
caught up in irrelevant presuppositions about what was a function or what wasn't.
For example,
#'(lambda (&rest arguments) (apply (coerce x 'function) arguments))
would both make your local intent clearer and make this proposal more modular.
I'll take care of ammending it in a few days after I make sure there are no other
comments.
∂23-Jun-88 0842 CL-Cleanup-mailer Re: Issue: ALIST-NIL (Version 1)
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 23 Jun 88 08:42:46 PDT
Date: 23 Jun 88 11:26:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Subject: Re: Issue: ALIST-NIL (Version 1)
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
cc: vanroggen
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
You didn't mention that the [R]ASSOC[-IF[-NOT]] functions might be
faster if they didn't have to check for NIL.
In general, I'm in favor of this, but I'm somewhat concerned about
compatibility. However, I think "Cost to User #1" isn't really much
of an argument. #2 is an issue, though, and your suggestion isn't
good enough a work-around, since it might change the behavior for the
xxx-IF and xxx-IF-NOT functions, depending on the predicate used.
---Walter
------
∂23-Jun-88 1005 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 10:05:16 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423715; Thu 23-Jun-88 13:05:03 EDT
Date: Thu, 23 Jun 88 13:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DEFINITION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623130442.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FUNCTION-DEFINITION
References: none
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
Proposal (FUNCTION-DEFINITION:OPTIONAL):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information, or to provide
primitives for flushing some or all of the information at any time.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is trivial. The following implementation is technically
legitimate, although many implementations would want to provide something
more useful:
(DEFUN FUNCTION-DEFINITION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL NIL NIL))
Proposal (FUNCTION-DEFINITION:REQUIRED):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information in file
compilations. In-core calls to EVAL and COMPILE would be required to
retain the information, however.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Additionally, this would be useful to programs which need to pass
around both a function and a representation of a function because a
single object could be passed which was efficient to call without
compromising the ability to reliably retrieve its representation.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is small, but not trivial. A simple implementation
might allocate a slot in each function that could hold the definition,
or might allocate a hash table to hold the information.
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
because it is considerably more useful in practice, but would like to see at
least FUNCTION-DEFINITION:OPTIONAL.
∂23-Jun-88 1254 CL-Cleanup-mailer Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 12:54:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423827; Thu 23-Jun-88 15:54:01 EDT
Date: Thu, 23 Jun 88 15:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623155341.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Ok, I've revived this proposal per discussion in committee with
corrections to just treat echo streams (as created by MAKE-ECHO-STREAM)
and not get caught up in the problems of terminal interaction.
Please read carefully. A lot of little things changed in the process
and I don't guarantee this is error-free.
Naturally, if we could agree to just go forward with one of the two
proposals, the thing would be textually a bit simpler...
-----
Issue: PEEK-CHAR-READ-CHAR-ECHO
References: READ-CHAR (p379), UNREAD-CHAR (p379), PEEK-CHAR (p379),
MAKE-ECHO-STREAM (p330), Streams (p327-328),
READ-PRESERVING-WHITESPACE (p376),
READ-DELIMITED-LIST (p377)
Category: CLARIFICATION/CHANGE
Edit history: 06-Mar-88, Version 1 by Pitman,
23-Jun-88, Version 2 by Pitman (remove interactive stuff)
Status: For Internal Discussion
Problem Description:
The interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM is not made adequately clear about how many times
a particular character may be echoed and at what time such echo
is permissible.
For example, given:
(WITH-INPUT-FROM-STRING (STRING-STREAM "A")
(LET ((*STANDARD-INPUT* (MAKE-ECHO-STREAM STRING-STREAM
*STANDARD-OUTPUT*)))
(LET ((CHAR NIL))
(PEEK-CHAR) (PRIN1 '---)
(PEEK-CHAR) (PRIN1 '---)
(SETQ CHAR (READ-CHAR)) (PRIN1 '---)
(UNREAD-CHAR CHAR) (PRIN1 '---)
(READ-CHAR))))
what is seen on the terminal? There are at least these possibilities:
[1] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. The first time
a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not echo,
re-fetching the char by READ-CHAR doesn't echo.
A------------
[2] Characters are echoed whenever seen by PEEK-CHAR or READ-CHAR.
Characters are not unechoed by UNREAD-CHAR.
A---A---A---A---
[3] Characters are not echoed by PEEK-CHAR but are echoed by READ-CHAR.
No `unecho' action is done by UNREAD-CHAR.
------A------A
[4] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR does not `unecho'.
A---A---A------A
[5] PEEK-CHAR is implemented by READ-CHAR/UNREAD-CHAR. READ-CHAR echos
but UNREAD-CHAR unechos (a magic Erase character must be
presupposed for display terminals, a file stream that can randomly
access during output and/or back up must be presupposed for files,
paper terminals just lose):
A<Erase>---A<Erase>---A---<Erase>---A
[6] PEEK-CHAR is implemented by peeking and does not echo. The first
time a char is seen by READ-CHAR it's echoed, UNREAD-CHAR does not
echo, re-fetching the char by READ-CHAR doesn't echo:
------A------
This list is not believed to be exhaustive. It is only to illustrate
of the variety of possible ways in which the current specification can
be implemented without technically being in conflict with the written
word of CLtL. Obviously not all of these interpretations are considered
useful by all people, but usefulness has not been determined to be
criterial in satisfying the specification.
The description of streams (p327-328) is also [probably deliberately]
fuzzy on this issue as it relates to operating systems on which echoing
is done by the operating system. That is, some systems are line-at-a-time
and all READ-CHAR and PEEK-CHAR operations happen after issues of echo
have long since been resolved by a system call that reads and echos input
a line at a time. Other systems are character-at-a-time and these issues
hit home in a different way. It will probably be necessary to continue
leaving things slightly unspecified in order to accomodate the native
style of the variety of operating systems now trying to support Common
Lisp, but we should be more up front about the game we are playing. (For
example, code which must port between character-at-a-time and
line-at-a-time systems must be more careful about whether it does
newline-preceded or newline-terminated output than many CL programmers
might realize given the current wording.) Additionally, though, we should
be on the lookout for less ambitious goals involving only partial
compatibility to improve the situation wherever we can find a way to.
Abstract functions READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST
are implicitly affected by any decisions made on this issue since their
descriptions involve the use of UNREAD-CHAR and PEEK-CHAR, respectively.
Proposal (PEEK-CHAR-READ-CHAR-ECHO:READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream at the time this operation is performed.
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
will be made to undo any echoing of the character which might already
have been done on the stream.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), characters
which are only peeked at are not echoed. Note however that in the
case that the PEEK-TYPE argument is not NIL, the characters which
are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
echoed.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [3] in the problem description.
Clarify that the echo behavior of interactive streams such as
*TERMINAL-IO* continues to be implementation dependent.
Rationale:
This is in use in a number of systems and few problems have been
reported. However, the reason there are so few reports may be that
few people use echo streams or that people who care about echo
behavior just avoid UNREAD-CHAR as too unpredictable (perhaps using
more reliable implementation-dependent primitives).
Proposal (PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR):
Ammend the description of READ-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), the character
will be echoed on the stream the first time those characters are seen.
(Characters which are not echoed by READ-CHAR are those which were
put there by UNREAD-CHAR and hence are assumed to have been echoed
already by a previous call to READ-CHAR.)
Ammend the description of UNREAD-CHAR to say that when the stream
is an echo stream (a stream created by MAKE-ECHO-STREAM), no attempt
will be made to undo any echoing of the character which might already
have been done on the stream. However, characters placed on the
stream by UNREAD-CHAR will be marked in such as way as to inhibit
later re-echo by READ-CHAR.
Ammend the description of PEEK-CHAR to say that when the stream is
an echo stream (a stream created by MAKE-ECHO-STREAM), characters
which are only peeked at are not echoed. Note however that in the
case that the PEEK-TYPE argument is not NIL, the characters which
are passed by PEEK-CHAR are treated as if by READ-CHAR, and so are
echoed unless they have been marked otherwise by READ-CHAR.
Ammend the description of abstract input functions
READ-PRESERVING-WHITESPACE and READ-DELIMITED-LIST to acknowledge
that they are implicitly affected by these new echoing rules of
READ-CHAR, UNREAD-CHAR, and PEEK-CHAR.
Note: This is consistent with behavior [6] in the problem description.
Clarify that the echo behavior of interactive streams such as
*TERMINAL-IO* continues to be implementation dependent.
Rationale:
Although this is not known to be in use in any particular system,
nothing prevents its use. It proposes a more rational interpretation
of the echoing behavior of UNREAD-CHAR which might make it possible
for programmers concerned about echo behavior not to have to shy
away from UNREAD-CHAR. (It would probably also improve the behavior
of READ-PRESERVING-WHITESPACE with regard to echoing, since its
description mentions using UNREAD-CHAR.)
Rationale:
Correct echoing behavior is important to programs which do batch
processing, parsing, etc. Allowing multiple or premature echoing
is clearly unsatisfactory.
Either of these proposals is an improvement over existing practice.
Current Practice:
A wide variety of behaviors are in use.
Cost to Implementors:
The code to implement the proposed change itself is probably fairly
localized.
In some operating systems, there may be echoing constraints which
I am overlooking. Depending on what those are, I may be
over-trivializing the difficulty of adopting these for some
implementations. I invite informed commentary on this issue.
In some cases, there may be second order effects in the system
itself which would also require a somewhat less predictable amount
of work to fix. In most cases, my hope is that the work would be
slight only because I assume that anyone who was going to rely on
a particular echo behavior for anything major would have realized
that CLtL wasn't guaranteeing this point and would have sent mail
complaining about this problem a lot sooner. Since no one has made
much noise about this, my hope is that it hasn't affected too many
people yet.
Cost to Users:
Any change is effectively upward compatible since the previous
behavior is so ill-specified.
Most users probably naively expect (perhaps even without realizing
it explicitly) that echoing will take care of itself. That is, they
probably expect that echoing will occur at the time of the
READ-CHAR and probably do not give a lot of thought to the effect
of PEEK-CHAR. As such, FIRST-READ-CHAR probably best supports most
of their naive intuitions.
Cost of Non-Adoption:
The streams returned by MAKE-ECHO-STREAM would continue to be
significantly hard to use portably.
Benefits:
A number of applications involving of parsers, batch script
interpreters, and such would be possible to implement
straightforwardly and portably.
Aesthetics:
[Thoughts anyone? -kmp]
Discussion:
Pitman supports PEEK-CHAR-READ-CHAR-ECHO:FIRST-READ-CHAR because
he feels it is more practically coherent. However, he says he has
only mental exercises and no actual personal experience upon which
to base that belief.
Version 1 of this proposal treated interactive streams on par
with echo streams, but while people agreed that this issue is
a severe portability problem, some considered that the treatment
of interactive streams got involved in operating system issues
that were beyond the scope of the standard, so that part of the
text was removed.
∂23-Jun-88 1412 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 14:12:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423898; Thu 23-Jun-88 17:11:49 EDT
Date: Thu, 23 Jun 88 17:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
This can contribute to syntactic conciseness, and may sometimes
even make things easier for a compiler to recognize and compile
efficiently.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added.
Current Practice:
No Common Lisp implementations provide these primitives, but they do
exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Pitman supports the inclusion of these primitives.
∂23-Jun-88 1516 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Jun 88 15:16:52 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Jun 88 18:16:42 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: Your message of Thu, 23 Jun 88 17:11:00 -0400.
<880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 23 Jun 88 18:16:22 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Presumably the following is a typo, and you intend this to a function that
calls the given function and then negates its argument. Or something like
that.
---------------------------------------------------------------------------
COMPLEMENT function [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
---------------------------------------------------------------------------
This all seems a bit gratuitous to me, but if the rest of you think it
would promote better programming style, I won't argue.
-- Scott
∂24-Jun-88 0912 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88 09:12:06 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424181; Fri 24-Jun-88 12:11:52 EDT
Date: Fri, 24 Jun 88 12:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 23 Jun 88 18:16 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880624121129.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 23 Jun 88 18:16:22 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Presumably the following is a typo ...
Yup.
... This all seems a bit gratuitous to me, but if the rest of you
think it would promote better programming style, I won't argue.
Well, I'm not passionate about this issue, but times have changed a lot
since the last time this issue came up. Functional programming styles
are much more respectable to talk about now. I just wanted to give people
a chance to react to them anew.
∂24-Jun-88 1058 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88 10:58:26 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424262; Fri 24-Jun-88 13:58:12 EDT
Date: Fri, 24 Jun 88 13:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 4)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624135739.7.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Don't panic -- Versions 1-3 were circulated between Dick Waters and myself
and did not reach this list. This is the first version CL-Cleanup should
have seen.
Also, please be sure to cc Dick@WHEATIES.AI.MIT.EDU in any correspondence
on this issue since he's not on CL-Cleanup.
-kmp
----------
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
Status: For Internal Discussion
Problem Description:
Currently, there is no portable way to inquire about the line width
of an output stream, the current character position on a line
or the amount of space that the display of a string will take up.
This makes it essentially impossible to write a portable
implementation of a pretty printer.
Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):
Introduce four new functions:
OUTPUT-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns the maximum line width that can be printed on the
OUTPUT-STREAM without causing truncation or wraparound. The
result is returned as a non-negative integer, or NIL if the stream
has no meaningful width (or the width cannot be computed). The
unit of width is arbitrary, however, given a particular output
stream, the unit must have some fixed value.
OUTPUT-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns the current horizontal position of the cursor on the given
OUTPUT-STREAM as a non-negative integer, or NIL if it cannot be
computed. (The position is the position of the distance of the
left edge of the cursor from the left margin. I.e., 0 means
cursor is at the left end of a line.) The units are arbitrary,
but for a given stream, they must be the same as the units used by
OUTPUT-WIDTH.
STRING-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
The START and END parameters delimit a substring of string in the
usual manner. STRING-WIDTH returns the change in output position
that would occur if STRING were written to OUTPUT-STREAM using
(WRITE-STRING STRING OUTPUT-STREAM :start START :end END) given
the current state of OUTPUT-STREAM or NIL if the change cannot be
computed. The returned value is an integer. The units are
arbitrary, but for a given stream, they must be the same as the
units used by OUTPUT-WIDTH. STRING-WIDTH satisfies the following
constraint.
(LET* ((STREAM ...)
(STRING ...)
(CURRENT-X (OUTPUT-POSITION STREAM)))
(= (STRING-WIDTH STRING STREAM)
(- (PROGN (WRITE-STRING STRING STREAM)
(OUTPUT-POSITION STREAM))
CURRENT-X)))
STRING-WIDTH does not return any indication of the vertical
distance required when printing string. Merely the difference in
horizontal position before and after printing. This difference
may be negative (e.g., if STRING contains backspace or newline
characters.) It is possible that the width of a string will
depend on the horizontal position where output begins (e.g., if
the string contains tab characters.) If this is the case, the
width returned assumes that the output occurs starting at the
current horizontal position in the stream. Similarly, the width
of string may depend on other aspects of the state of
OUTPUT-STREAM (e.g., the font being used). In all respects the
width is computed based on the current state of the stream.
STRING-WIDTH never causes any change in the state of OUTPUT-STREAM.
OUTPUT-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
This function causes blank space to be inserted in OUTPUT-STREAM
so that the output position is increased by WIDTH. WIDTH is an
integer. The units are arbitrary, but for a given stream, they
must be the same as the units used by OUTPUT-WIDTH. A negative
WIDTH parameter indicates backspacing. The unit of WIDTH should
be chosen so that it is possible to move the output position left
and right by a single unit. OUTPUT-SPACE satisfies the following
constraint.
(LET* ((STREAM ...)
(N ...))
(= (+ (OUTPUT-POSITION STREAM) N)
(PROGN (OUTPUT-SPACE N STREAM)
(OUTPUT-POSITION STREAM))))
OUTPUT-SPACE returns T if the spacing operation has been achieved
and NIL otherwise (e.g., if the requested spacing would move off
of the end of the line or if the the operation cannot be supported
for the given stream.)
A key motivation behind the functions above is dealing with
output streams that support variable length fonts. The unit of
width is allowed to vary from stream to stream in order to allow
for differences between output devices. The only thing that
matters is that the four functions above operate on the same units
when given the same stream.
If an output stream only supports a single fixed width font, the
logical choice of width unit is the length of a single character.
In this situation (and ignoring characters such as tab, newline,
and other control characters that do not have an output width of
one) the functions above have the following simple meanings.
OUTPUT-WIDTH returns the maximum number of characters which can be
printed on a single line. OUTPUT-POSITION returns the number of
characters which have already been printed on the current line.
STRING-LENGTH returns the number of characters in the string.
OUTPUT-SPACE prints the specified number of space, or backspace,
characters.
Another key feature of the functions above is that they are all
permitted to return NIL without performing any action. This is to
allow for the fact that the required operations might not be
supported for every kind of stream. However, it is hoped that the
functions would in fact be supported for most kinds of streams.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(output-width S) => 72
(terpri S)
(output-position S) => 0
(string-width "testing: " S) => 9
(write-string "testing: " S)
(output-position S) => 9
(write-string "foo" S)
(terpri S)
(output-space 9 S) => T
(write-string "bar" S)
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function OUTPUT-WIDTH in order to know
how wide the output it produces can be. Pretty printing requires
OUTPUT-POSITION in order to determine where on the line output is
when pretty printing starts. Pretty printing requires STRING-WIDTH
in order to determine how much space things will take in the output.
(If a variable width font is being used, this cannot be determined
without a detailed knowledge of the font being used.) Pretty
printing requires OUTPUT-SPACE in order to get proper indentations.
(If a variable width font is being used, indentations may be
required that cannot be obtained by outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
functionality above internally in order to support PPRINT and the
FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations which
do not have the ability to compute difficult values to just return NIL.
Very little work is forced. The idea is to offer implementors a common way
to provide this useful information to portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
Dick Waters submitted a request for changes along the line of the
horizontal aspects of these functions in a letter to X3J13 dated
June 14, 1988. Pitman and Waters wrote up the request formally.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
required in order to support pretty printing into a stream which
displays output using a variable width font.
We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
which goes significantly beyond what is needed merely for pretty printing
and provides primitives OUTPUT-DIMENSIONS, OUTPUT-POSITION,
STRING-DIMENSIONS, and OUTPUT-SPACE but it is not included here.
A key point of contention which would be likely to swamp the 2d proposal
is the age old question of how to handle the issue of vertical distance
(where is the origin, which way do you count, ...). If anyone would
prefer to see larger problem 2d proposal, it could be circulated, but at
the last minute Pitman got worried that even the 1d version was going to
be controversial enough and decided to keep things focused on that.
For his own needs, Waters is strongly interested in having either
ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
but does not care which. Pitman concurs.
One variation of the 1d proposal might be useful to consider:
STRING-WIDTH could return two additional values: the number of newlines
that WRITE-STRING of the string would execute and the maximum X position
encountered (which might differ from the first value if the number of
newlines was non-zero).
This feature wasn't necessary for Waters' minimalist proposal, but Pitman
would be willing to write it in here if people thought it would be useful
enough for other purposes.
∂24-Jun-88 1100 CL-Cleanup-mailer Issue: STRUCTURE-INFO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88 11:00:21 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 424268; Fri 24-Jun-88 14:00:04 EDT
Date: Fri, 24 Jun 88 13:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STRUCTURE-INFO (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624135946.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Please be sure to cc Dick@WHEATIES.AI.MIT.EDU in any correspondence
on this issue since he's not on CL-Cleanup.
-kmp
----------
Issue: STRUCTURE-INFO
References: Structures (pp305-320)
Category: ADDITION
Edit history: 24-Jun-88, Version 1 by Pitman and Waters
Status: For Internal Discussion
Problem Description:
There is no portable way to determine whether something is a structure
and no portable way to ask abstractly what the contents of a structure
are without understanding that particular structure.
Proposal (STRUCTURE-INFO:NEW-FUNCTIONS):
Introduce these new functions:
STRUCTUREP thing [Function]
Predicate returns true if the given object is represented as
a structure (without the use of DEFSTRUCT's :TYPE option).
Otherwise, returns false.
STRUCTURE-CONTENTS structure [Function]
Returns an alist of field names (as keywords) and field values showing
the contents of the STRUCTURE. The STRUCTURE may be any object
for which STRUCTUREP returns true.
Test Case:
(DEFSTRUCT (FRED (:TYPE VECTOR)) (A 1) (B 2) (C 3))
(SETQ FRED (MAKE-FRED))
(STRUCTUREP FRED) => NIL
(VECTORP FRED) => T
(STRUCTURE-CONTENTS FRED) is undefined
(DEFSTRUCT WILMA (A 1) (B 2) (C 3))
(SETQ WILMA (MAKE-WILMA))
(STRUCTUREP WILMA) => T
(STRUCTURE-CONTENTS WILMA) => ((:A . 1) (:B . 2) (:C . 3))
Rationale:
STRUCTUREP is important for implementing a portable pretty printer in
a number of ways. STRUCTURE-CONTENTS is less important, but is necessary
if a portable pretty printer is to print structures in #S notation.
Current Practice:
Some implementations, such as Symbolics Genera, provide
(TYPEP x 'STRUCTURE).
Most implementations do not go so far as to provide STRUCTUREP, however.
Probably no implementations offer STRUCTURE-CONTENTS in any exported form.
Cost to Implementors:
Since the standard printer must access this same information when
printing structures, it must be very trivial to provide this functionality.
Cost to Users:
None. This is an upward compatible change.
Cost of Non-Adoption:
Portable pretty printers would not be able to pretty-print structure
objects in #S notation.
Benefits:
In addition to pretty printers, this might be of some use to programmers
customizing the generic function DESCRIBE, or to people writing
DESCRIBE-like facilities.
Aesthetics:
No major aesthetic impact.
Discussion:
Dick Waters submitted a request for changes of this kind in a letter to
X3J13 dated June 14, 1988. Pitman wrote up the request formally.
If the CLOS meta-object protocol becomes a standard part of CL, this
facility would not be necessary. However, if that protocol is in any way
optional, it would be useful to have this interface since it can be
implemented using considerably less powerful primitives than that
protocol offers.
∂24-Jun-88 1149 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88 11:49:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 11:42:59 PDT
Date: 23 Jun 88 00:53 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 24 Jun 88 13:57 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, DICK@WHEATIES.AI.MIT.EDU
Message-ID: <880624-114259-5815@Xerox>
"Returns the current horizontal position of the cursor..."
The word "cursor" is unfortunately overused and not defined here or elsewhere in
CLtL.
What is
(with-output-to-string (x ) (princ "a test") (output-position x))?
Is it implementation dependent?
What is (output-position *terminal-io*)? What is the relation between
(output-position (make-broadcast-stream a b)) and (output-position a) and
(output-position b)?
I'm sure I can think of more questions given time...
∂24-Jun-88 1209 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Jun 88 12:09:13 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 424326; 24 Jun 88 15:08:21 EDT
Date: Fri, 24 Jun 88 15:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880624-114259-5815@Xerox>
Message-ID: <880624150813.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
We'll see if we can add enough description of a cursor to make
the proposal more clear.
It's good to have the hard issues listed out, and they should probably be
in the discussion section, but since you're permitted to return NIL on any
case you think is too hard, I hope the proposal doesn't get stalled on that.
The important point here is that many implementations -do- have a theory
of where the cursor is in some or all of those situations, and if the
implementation has a theory, Dick just wants to be able to access that info.
The idea isn't to make more work for implementors -- only to make a common
interface to this facility where it does exist. As it is, you have to
use a lot of #+ and #- stuff to deal with this -- and every time a new
implementation comes along, it has to decide which existing implementation
to use as a pattern or whether to make up its own protocol.
∂24-Jun-88 1225 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88 12:25:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:18:12 PDT
Date: 24 Jun 88 12:17 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 24 Jun 88 15:08 EDT
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880624-121812-5897@Xerox>
While relying on implementation-specific heuristics for implementation-specific
streams seems right to me, it seems less clear for streams that are created
using otherwise portable mechanisms. For example, we could define that for
string streams created , the line width is the value of *string-stream-width*
(and encapsulated in the stream), where NIL means infinite, and that the unit
of width is 1 and that every character takes exactly 1 character, that
two-way-streams and echo-streams inherit the position and width of their output
streams, that broadcast streams inherit from their first component.
∂24-Jun-88 1307 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 24 Jun 88 13:07:45 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 24 JUN 88 12:56:50 PDT
Date: 24 Jun 88 12:56 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 23 Jun 88 18:16:22
EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880624-125650-6005@Xerox>
I think this stuff might be useful, but it falls into the category of a package
of useful things that we should distribute. Compare the situation with LOOP,
where the proliferation of incompatible LOOP macros is a serious problem. Is
there a problem with proliferation of versions of these?
∂24-Jun-88 1552 CL-Cleanup-mailer EQUAL
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Jun 88 15:52:33 PDT
Received: by labrea.stanford.edu; Fri, 24 Jun 88 15:52:27 PDT
Received: from bhopal.lucid.com by edsel id AA07541g; Fri, 24 Jun 88 14:38:25 PDT
Received: by bhopal id AA16670g; Fri, 24 Jun 88 14:38:05 PDT
Date: Fri, 24 Jun 88 14:38:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806242138.AA16670@bhopal.lucid.com>
To: RWK@ai.ai.mit.edu
Cc: edsel!jlm@labrea.stanford.edu, common-lisp@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: "Robert W. Kerns"'s message of Mon, 13 Jun 88 02:05:15 EDT <396357.880613.RWK@AI.AI.MIT.EDU>
Subject: EQUAL
[apologies for so late a reply -- have been out of town for over a week]
Jim's point about the historical reference of EQUAL seemed to me to be that
it was made to work for the datatypes that were "in common use" in the Lisps
of that day, namely the datatypes necessary for writing programs in the
Lisp language. Hence, conses, symbols, numbers, maybe strings, and not
much else.
However, I certainly wouldn't expect anything productive to come from a
discussion on how to determine whether two programs/functions *really*
are "equal"! Possibly you took MacDonald's argument to an extreme that
he didn't originally intend?
What would be the objections to extending EQUAL to accommodate the serious
modern datatypes of Common Lisp? in particular:
(1) Do component-wise EQUAL comparisons on arrays [this implies "descent"
for pointer arrays]. Unlike with EQUALP, the arrays must be of the
same type, but the presence of fill-pointers, array-element-type
"upgrading", adjustability, and displacement may require some
refinements of this clause.
(2) Descend defstructs, except possibly for "system" defstructs that
are built-in by the implementation [i.e., an implementation can
use defstruct to implement a STREAM, but impose a "private"
definition of EQUAL for streams; probably same for all types
discussed in the cleanup issue TYPE-HIERARCHY-UNDERSPECIFIED].
Possibly extend defstruct to admit an option :equal, similar to
the :copier option, but this isn't a critical requirement now.
(3) Require that EQUAL be a "generic" function, so that CLOS methods
can be written for it; likely, the "default" method for non-built-in
classes would be some sort of error, meaning that mindless descent
isn't a good default. By analogy with defstructs, you can compare
two defstuct-instances of the same type with the :equal functions,
and you could only compare two clos instances for which there is an
appropriate EQUAL method supplied.
This definition would imply that hashtables of :type EQUAL will operate in
the manner expected by so many users of Common Lisp. Somehow, people have
been lured into thinking that this is already the current practice; but of
course something much more limiting is the current state.
Finally, I might point out that recent discussions about EQUALP seem to
have overlooked it's variations on numerical equality and array-type
indifference. Extending EQUAL to descend structures is *not* the same
as retracting EQUALP to be case-sensitive.
-- JonL --
∂24-Jun-88 1647 CL-Cleanup-mailer EQUAL
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 24 Jun 88 16:47:42 PDT
Received: by labrea.stanford.edu; Fri, 24 Jun 88 16:47:38 PDT
Received: from bhopal.lucid.com by edsel id AA08086g; Fri, 24 Jun 88 16:40:19 PDT
Received: by bhopal id AA18154g; Fri, 24 Jun 88 16:39:58 PDT
Date: Fri, 24 Jun 88 16:39:58 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8806242339.AA18154@bhopal.lucid.com>
To: edsel!jonl@labrea.stanford.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Fri, 24 Jun 88 14:38:13 EST <8806242138.AA16670@bhopal.lucid.com>
Subject: EQUAL
My concern about having EQUAL descend structures and arrays is that
they are much more likely than lists to be circular.
Typically, a list is created after its elements, whereas a structure
or array is created before its elements. (*Typically*, not always!)
As a rule of thumb, I'd bet that less than .0001% of all lists are
circular, and that less than 1% of all arrays are circular, but only
that less than 30% of all structures are circular.
I think there is a tendancy to include fields like CHILDREN and
PARENTS, or PREVIOUS and NEXT, etc. in structures, which are thus
almost guaranteed to be circular. In fact, when I'm creating circular
data I tend to think first of using structures, because I am then less
likely to get screwed by EQUAL, etc.
I don't have time now to think through the algorithmic details, but
maybe DEFSTRUCT could let you specify that specific slots are
"back-pointers". Then EQUAL could record them when descending and
perform a more sophisticated comparison than it would for all other
pointers. Thus you would only pay at runtime for the specific
complications you did introduce, not those you might have. Making
backpointers explicit might help human readability as well.
[As something of an aside, I think you should also be able to specify
*print-level* and *print-length* for specific structure fields, to
avoid losing on some fields when trying to see others.]
jlm
∂27-Jun-88 0753 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jun 88 07:53:34 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425042; Mon 27-Jun-88 10:48:33 EDT
Date: Mon, 27 Jun 88 10:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: Masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880624-121812-5897@Xerox>
Message-ID: <880627104822.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 24 Jun 88 12:17 PDT
From: Masinter.pa@Xerox.COM
While relying on implementation-specific heuristics for implementation-specific
streams seems right to me, it seems less clear for streams that are created
using otherwise portable mechanisms. For example, we could define that for
string streams created , the line width is the value of *string-stream-width*
(and encapsulated in the stream), where NIL means infinite, and that the unit
of width is 1 and that every character takes exactly 1 character,
This might be useful. It should be clear that you mean string streams created
by a CL primitive and not arbitrary string streams, though, since implementations
might have other theories on other streams. Also, actually, I think it should
somehow be streams of STRING-CHAR only, since arbitrary chars may have fonting
information and it may in some cases be clear to an implementor that this portable
model is not appropriate. I'd hate to tie an implementor's hands....
that two-way-streams and echo-streams inherit the position and width of their
output streams,
Ok since they have a unique output stream (no ambiguity).
that broadcast streams inherit from their first component.
Perhaps, but this I'm less sure of and might be inclined to leave as
undefined. It might, for example, make more sense for an implementation
to use the MIN of the width of the streams. Also, it might make sense
for an implementation to canonicalize the units so if stream1 were fixed
width (char=1) and stream2 were pixel-based, the merged stream might
report in pixels so even if it used stream1's information, it might not
-look- like stream1's information, so it might be misleading to say it
was.
I'm ammenable to a rewrite of this proposal per these suggestions if you
wanted to do that (and if no one else had a dissenting opinion). The
original intent (and the reason I didn't mail out the 2d proposal) was
to keep things simple. I don't want to add any hair that will make it
harder for this to pass x3j13, but things that seem reasonable to
everyone are ok by me...
∂27-Jun-88 0817 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88 08:17:22 PDT
Received: by rice-chex.ai.mit.edu; Mon, 27 Jun 88 11:19:15 EDT
Date: Mon, 27 Jun 88 11:19:15 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806271519.AA01551@rice-chex.ai.mit.edu>
To: Masinter.pa@xerox.com
Cc: CL-Cleanup@sail.stanford.edu, KMP@stony-brook.scrc.symbolics.com
In-Reply-To: Masinter.pa@xerox.com's message of 24 Jun 88 12:17 PDT <880624-121812-5897@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
While relying on implementation-specific heuristics for
implementation-specific streams seems right to me, it seems less clear
for streams that are created using otherwise portable mechanisms.
This is a good point. However, I agree with KMP that we do not want to load
this proposal up with a lot of baggage.
For example, we could define that for string streams created, the line
width is the value of *string-stream-width* (and encapsulated in the
stream), where NIL means infinite, and that the unit of width is 1 and
that every character takes exactly 1 character,
Here, it seems to me that that logical width of a string stream is
infinity. I would not add any extra hair. It is the user who
presumably has some theory about how wide the stream should be. Any
reasonable pretty printer or the like will have a way for the user to
override the inherent width of a stream.
that two-way-streams and echo-streams inherit the position and
width of their output streams,
This sounds good to me.
that broadcast streams inherit from their first component.
I agree with KMP's comments on this. Things do not seem all that simple.
Dick
∂27-Jun-88 0834 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88 08:33:51 PDT
Received: by rice-chex.ai.mit.edu; Mon, 27 Jun 88 11:35:44 EDT
Date: Mon, 27 Jun 88 11:35:44 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806271535.AA01655@rice-chex.ai.mit.edu>
To: Masinter.pa@xerox.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 23 Jun 88 00:53 PDT <880624-114259-5815@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
"Returns the current horizontal position of the cursor..."
The word "cursor" is unfortunately overused and not defined here or
elsewhere in CLtL.
Cursor is indeed a vague word. Perhaps we could just say THAT
"OUTPUT-POSITION returns the total net width of all of the
characters written to the stream since that last <newline> character
(or since the creation of the stream if no <newlines> have ever been
written).
What is (with-output-to-string (x) (princ "a test") (output-position x))?
Is it implementation dependent?
There is really a key point here. Yes it is implementation dependent.
In particular, the values returned cannot be used for anything but
comparing with each other. For example, if the output-width is not
nil, then the value of output-position can be compared with it to
determine how close you are to the end of the line (in percent, but
not by any absolute measure.) [With a string-stream the logical
output-width is assumedly nil.]
Another use of output-position is that no matter what number
output-position returns, sending a <newline> to the stream and then
calling output-space with the same number will get you back to the
same horizontal place.
The proposal is carefully crafted to give you these two capabilities
while adding as few other constraints as possible.
----------------------------------------------------------------------
NOTE, a broadcast stream must keep track of the relationships between
the units of width used by the actual target streams so that
output-space requests can be translated correctly when they are
broadcast to all of the actual targets.
Dick
∂27-Jun-88 1238 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Jun 88 12:38:20 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425383; Mon 27-Jun-88 15:38:00 EDT
Date: Mon, 27 Jun 88 15:37 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880627153746.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PATHNAME-TYPE-UNSPECIFIC
References: Pathnames (pp410-413)
Category: CHANGE
Edit history: 27-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL (p412) specifies that the type is ``always a string, NIL,
or :WILD.'' This description is too restrictive to be practical.
In file systems which have no first-class notion of a name/type
distinction, it is possible to make files named "foo." and "foo"
which are distinct. One of these (usually the former) can get a
type of "" but it is not clear how to represent the other. If
NIL is used, merging primitives cannot detect that the field is
filled and should not be merged against.
Proposal (PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN):
Permit :UNSPECIFIC as a value of the type field of a pathname for
operating systems in which it makes sense.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC
both cause the component not to appear in the string.
When merging, however, a NIL value for a component will be replaced
with the default for that component, while :UNSPECIFIC will be left
alone.
Test Case:
For file systems where :UNSPECIFIC makes sense...
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC)
(MAKE-PATHNAME :TYPE "FOO")))
Rationale:
This is, by necessity, current practice in some implementations
already.
Current Practice:
Symbolics Genera uses a file type of :UNSPECIFIC on Unix and
ITS file systems, for example.
Cost to Implementors:
None. No change to any implementation is forced.
Some implementations which use a non-standard token other than :UNSPECIFIC
to implement this functionality might want to switch to use :UNSPECIFIC so
that portable programs could expect it.
Cost to Users:
Some programs which manipulate pathnames should be updated to expect
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really
portable, however, given that some implementations have been forced to
go beyond the standard in order to represent all possible pathnames.
Cost of Non-Adoption:
Some implementations would be unable to both represent all possible pathnames
in a rational way and at the same time to conform to the standard.
Benefits:
Some programs involving pathnames would be more portable.
Aesthetics:
Sweeping a hairy situation under the rug doesn't make it go away.
This change makes things appear less simple, but since in reality
they were less simple, it is effectively a simplification of the
correspondence between the CL model and reality.
Discussion:
Pitman supports PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed in the Colander draft edition of CLtL, but was
removed for the Laser edition. The following text is excerpted from
the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword
:UNSPECIFIC. This means that the component has been explicitly
determined not to be there, as opposed to be missing. One way
this can occur is with generic pathnames, which refer not to
a file but to a whole family of files. The version, and usually
the type, of a generic pathname are :unspecific. Another way
:unspecific is used to represent components that are not simply
supported by a file system. When a pathname is converted to a
namestring, nil and :unspecific both cause the component not to
appear in the string. When merging, however, a nil value for
a component will be replaced with the default for that
component, while :unspecific will be left alone.''
∂27-Jun-88 1357 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 1)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 27 Jun 88 13:57:07 PDT
Received: by labrea.stanford.edu; Mon, 27 Jun 88 13:57:02 PDT
Received: from bhopal.lucid.com by edsel id AA00331g; Mon, 27 Jun 88 12:29:22 PDT
Received: by bhopal id AA00551g; Mon, 27 Jun 88 12:29:15 PDT
Date: Mon, 27 Jun 88 12:29:15 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8806271929.AA00551@bhopal.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Thu, 23 Jun 88 17:11 EDT <880623171122.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 1)
The following is a sketch of some other possibly useful operators.
Maybe some kind soul out there will adopt them and make a real
proposal to add them.
Note that the notions of permutation-vector are actually just a
first stab--one might really want some lambda-list -> lambda-list
operator that understands &optional, &key, &rest, etc. It might
also be useful to have an operator that permitted deletion or
repetition of arguments.
I think the caveat about redefinition of the given function should
be added to the existing proposal and apply to all the composition
functions.
COMMUTE function [Function]
Returns a function whose value is the same as that of the
given function applied to the same arguments with the first
two interchanged.
PERMUTE function argument-permutation
&optional value-permutation [Function]
Returns a function whose values are a permutation of the
values which would be returned by an application of the given
function to a permutation of its arguments.
If argument-permutation is NIL, the effect is as if all
arguments were passed to the given function without being
permuted. If it is non-NIL, it must be a sequence of integers
containing a permutation of an initial subset of the natural
numbers, and the effect is as if each argument, at position i,
is first moved to position (elt argument-permutation i) before
the given function is called.
If values-permutation is NIL, the effect is as if values were
returned from the given function without being permuted. If
it is non-NIL, it must be a sequence containing a permutation
of an initial subset of the natural numbers, and the effect is
as if each value, at position j, is first moved to position
(elt value-permutation j) before the result function returns.
Note that in practice such argument and value movement could
be implicit in the behavior of the result function, and the
given function might never be called. Hence subsequent
redefinitions of the given function may have unpredictable
effects on the behavior of the result function.
Examples:
(FUNCALL #'(LAMBDA (X Y) (CONS Y X)) 1 2)
==
(FUNCALL (COMMUTE #'CONS) 1 2)
=>
(2 . 1)
(FUNCALL #'(LAMBDA (A B C D E F) (LIST C B A F E D)) 11 22 33 44 55 66)
==
(FUNCALL (PERMUTE #'LIST #(2 1 0 5 4 3)) 10 11 12 13 14 15 16)
=>
'(12 11 10 16 15 14)
(FUNCALL #'(LAMBDA (I J)
(MULTIPLE-VALUE-BIND (Q R)
(TRUNCATE I J)
(VALUES R Q)))
10 3)
==
(FUNCALL (PERMUTE #'TRUNCATE nil '(1 0)) 10 3)
=>
1
3
∂28-Jun-88 0919 CL-Cleanup-mailer
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88 09:19:22 PDT
Date: 28 Jun 88 12:04:00 EDT
From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
I dislike the names OUTPUT-WIDTH and OUTPUT-POSITION for several reasons:
(1) It's ambiguous--the "position" could be for the whole stream output
so far instead of just the current line.
(2) VAX LISP already has exactly the functionality of OUTPUT-POSITION but
with the name LINE-POSITION. VAX LISP also has a function called
RIGHT-MARGIN, which might be the same as OUTPUT-WIDTH, but I'm not sure.
Is the intent of OUTPUT-WIDTH to provide an indication to the pretty
printer of how far it knows it can print towards the side? Is it meant
to be an absolute limit, in that printing beyond that point is undefined?
What should the OUTPUT-WIDTH of string streams be? In VAX LISP, the
RIGHT-MARGIN of string streams is 80, but we allow users to override how
far the printer goes before inserting newlines.
A lesser name complaint is OUTPUT-SPACE might be better named WRITE-SPACE
to match the other WRITE-xxx functions.
---Walter
------
∂28-Jun-88 0943 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88 09:43:29 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425840; Tue 28-Jun-88 12:39:35 EDT
Date: Tue, 28 Jun 88 12:38 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 4)
To: vanroggen%bach.decnet@hudson.dec.com
cc: cl-cleanup@sail.stanford.edu, Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: The message of 28 Jun 88 12:04 EDT from "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
Message-ID: <880628123845.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Added Dick@WHEATIES.AI.MIT.EDU -- He's not on CL-Cleanup. Please
remember to CC him explicitly. -kmp]
Date: 28 Jun 88 12:04:00 EDT
From: "BACH::VANROGGEN" <vanroggen%bach.decnet@hudson.dec.com>
I dislike the names OUTPUT-WIDTH and OUTPUT-POSITION for several reasons:
(1) It's ambiguous--the "position" could be for the whole stream output
so far instead of just the current line.
(2) VAX LISP already has exactly the functionality of OUTPUT-POSITION but
with the name LINE-POSITION.
LINE-POSITION is ok by me.
VAX LISP also has a function called RIGHT-MARGIN, which might be the same
as OUTPUT-WIDTH, but I'm not sure.
I tried not to call it anything with the word "right" in it for the sake of
anyone who might get ambitious and want to do a Hebrew implementation that
went right to left. The text descriptions probably mention left/right all
over the place, but I felt that was less critical and easier to work around
than having the language primitives themselves be biased.
LINE-WIDTH would be consistent and ok with me, though.
Is the intent of OUTPUT-WIDTH to provide an indication to the pretty
printer of how far it knows it can print towards the side? Is it meant
to be an absolute limit, in that printing beyond that point is undefined?
The point beyond which things get ugly or wrap or truncated or whatever.
Undefined, I guess.
What should the OUTPUT-WIDTH of string streams be?
Someone proposed NIL, which seemed right to me.
In VAX LISP, the RIGHT-MARGIN of string streams is 80, but we allow
users to override how far the printer goes before inserting newlines.
It's so easy to do (OR (OUTPUT-WIDTH ...) 80) that I think it's a bad idea
to return a number if you don't mean it. If you do, it's hard to tell the
difference between an intentional and an accidental number. In the worst case,
there should be a DEFAULT argument, which defaults but can be overridden.
I doubt we'd all be able to agree on a number to which it should default,
though, so its value probably couldn't be relied upon portably.
A lesser name complaint is OUTPUT-SPACE might be better named WRITE-SPACE
to match the other WRITE-xxx functions.
---Walter
------
WRITE-SPACE sounds ok to me.
∂28-Jun-88 1000 CL-Cleanup-mailer
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88 10:00:33 PDT
Date: 28 Jun 88 12:47:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Could you specify the "technicality" referred to in the CURRENT PRACTICE
section (or leave out the argument)?
Either proposal is acceptable to me.
---Walter
------
∂28-Jun-88 1041 CL-Cleanup-mailer Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 28 Jun 88 10:41:05 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01118; Tue, 28 Jun 88 13:38:40 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA08214; Tue, 28 Jun 88 13:42:36 EDT
Message-Id: <8806281742.AA08214@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-OUTPUT-INITIAL-BINDING (version 5)
Date: Tue, 28 Jun 88 13:42:30 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Status: For Internal Discussion
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:CONTRACTS-AND-FUNCTIONS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as defined
in CLtL.
*TERMINAL-IO*
Is always bound to a writable two-way stream. It is legal for
input from *TERMINAL-IO* to always return EOF.
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these streams are undefined except
that none of these streams may be synonym-streams for another
one of these streams. Any or all of these streams may be
synonym streams for *TERMINAL-IO*. Any or all of these
streams may be synonyms for the same implementation-sepcific
stream.
Add the following inquiry functions to Common Lisp:
STREAM-SAME-DESTINATION-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams send their
output to the same "destination". For example, this function
would return true for two streams that output to Unix files iff
the streams resulted either in output to the same file
descriptor or in output to two different file descriptors for
the same inode.
STREAM-SAME-SOURCE-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams receive
their input from the same "source", where same source mans that
input on one stream will change what the other stream would next
read. For example, this function would return true for two
streams that read from Unix files iff the streams resulted in
input from the same file descriptor but not if the streams
resulted in in input from two different file descriptors for the
same inode because then reading one stream would not change what
the other stream saw.
STREAM-INTERACTIVE-P stream [Function]
Returns T if the Lisp can prove that the stream is interactive,
where interactive means that the stream is a two way stream
connected in such a way that output can result in a change in
succeeding input.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *STANDARD-ERROR*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
(IN2 (OPEN "foo" :DIRECTION :INPUT))
(OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
(OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
(STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
(STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
(LIST (STREAM-SAME-DESTINATION-P STREAM1 OUT1)
(STREAM-SAME-DESTINATION-P STREAM1 STREAM2)
(STREAM-SAME-SOURCE-P STREAM1 IN1)
(STREAM-SAME-SOURCE-P STREAM1 STREAM2)
(STREAM-INTERACTIVE-P STREAM1)
(STREAM-INTERACTIVE-P *TERMINAL-IO*)))
==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output. The inquiry functions answer questions that portable Lisp
programs can't answer on their own because the information is
frequently only maintained at an operating system level.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal. The new inquiry functions will require some work to write
correctly for each environment.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations. Portable programs will
have more tools for reasoning about stream relationships.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex. This problem should now be solved.
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Masinter doesn't believe that STREAM-SAME-SOURCE-P is needed; Pierson
disagrees.
The definition of STREAM-INTERACTIVE-P is intentionally vague because
it is not reasonable for the Lisp to try and distinguish between, say,
a terminal connection to a human and a pseudo terminal connection to
another program.
Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:CONTRACTS-AND-FUNCTIONS.
∂28-Jun-88 1100 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-UTILITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 28 Jun 88 10:58:14 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA10391; Tue, 28 Jun 88 10:58:00 PDT
Date: Tue, 28 Jun 88 10:58:00 PDT
Message-Id: <8806281758.AA10391@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: Issue: SYMBOL-MACROLET-UTILITY
Status: DRAFT
Issue: SYMBOL-MACROLET-UTILITY
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category: DELETION
Edit history: 21-Jun-88, Version 1 by Piazza
Problem Description:
Anything expressible with SYMBOL-MACROLET could also be written with
regular MACROLET, except that the macro symbol could not stand alone as an
expression; it would have to be enclosed in parentheses. The cost
associated with implementing and maintaining the SYMBOL-MACROLET feature
exceeds this incremental utility.
Proposal (SYMBOL-MACROLET:FLUSH):
Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.
Rationale:
Flushing SYMBOL-MACROLET eliminates the cost of implementing and
maintaining this feature, while MACROLET still provides most of
SYMBOL-MACROLET's expressive power.
------------------------------------------------------------------------------
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R.
Cost to Implementors:
Presumably few implementors have implemented SYMBOL-MACROLET, excepting
the implementation provided by PCL. If it is flushed from the language,
no one will incur any implementation cost.
Cost to Users:
Users will lose the expressive ability provided by SYMBOL-MACROLET,
WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with MACROLET.
Cost of Non-Adoption:
Implementors must implement significant new functionality, adding to
system size and language complexity. (A separate proposal,
SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
specified semantics of SYMBOL-MACROLET.)
Benefits:
SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
a Common Lisp implementation. It also simplifies the language by
eliminating the concept of a "symbol macro."
Aesthetics:
There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
as a construct in the language. Some feel it hairs up the language while
offering only trivial benefit beyond what is already provided through
normal macros. Others herald it as a important new language feature.
Discussion:
As it was adopted by X3J13 as part of CLOS, there has been no formal
discussion on the pros and cons SYMBOL-MACROLET on its own.
∂28-Jun-88 1137 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88 11:37:00 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 425928; Tue 28-Jun-88 14:34:26 EDT
Date: Tue, 28 Jun 88 14:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 5)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8806281742.AA08214@mist.UUCP>
Message-ID: <880628143405.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[Lest anyone become confused with all these issue names being so similar,
I note that the issue name is STANDARD-INPUT-INITIAL-BINDING as in the
body of your message, not STANDARD-OUTPUT-INITIAL-BINDING as in
your subject line.]
The proposal's wording is somewhat too vague for my taste. For example,
it first says htat the streams are as per CLtL and then it lists a bunch
of streams with commentary after some and not others. Does it mean to say
they are as per CLtL except as indicated? When indicated, does the info
augment or replace what is in CLtL?
There is no such thing as "returning EOF". I think you want to say that
*TERMINAL-IO* can be an empty stream. In the case that it is indeed empty,
it must behave like any other empty file (e.g., signalling an error when
the ERROR-P argument to the read function used is not NIL). I'm not sure
why the issue of an empty *TERMINAL-IO* input stream is addressed, but the
issue of a bit-sink output stream (output being discarded) is not addressed.
Is there a natural asymmetry that I'm not seeing?
The wording "The initial bindings of these streams are undefined" also
doesn't suffice. Streams don't have bindings, variables have bindings.
We must say that the stream variables are bound and that the initial
values of these stream variables are streams. It is the kind of stream
which they are which we can leave unspecified.
In the phrase "the same implemntation-specific stream", "same" has no
antecedent. I think you mean to be drawing some correspondence between
Lisp's *ERROR-OUTPUT* and some Unix/Vax/...-specific error output stream,
but you haven't said that clearly.
It is critical that it say somewhere that *TERMINAL-IO* may not initially
be a synonym stream to *STANDARD-OUTPUT*, *STANDARD-INPUT*. (Don't say that
it may not be a synonym stream at all; it's ok for it to be a synonym to
some internal stream, for example, it's just not ok for it to be a synonym
to one of the other stream variables.)
In place of STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P, I happen to
prefer the following:
STREAM-SOURCE-ID-LIST stream [Function]
STREAM-DESTINATION-ID-LIST stream [Function]
Returns a list of tokens which identify the source or destination of the
stream at the current time. The tokens may be any lisp objects
distinguishable using EQL. The only valid operation on the list of tokens
are non-desctructive set operations.
A synonym stream always returns the same id list as the stream to which
it is indirected.
An encapsulated stream (such as an echo stream or a broadcast stream)
always returns at least the union of the tokens which would be returned
by each of the encapsulated streams.
Your STREAM-SAME-DESTINATION-P and STREAM-SAME-SOURCE-P would be possible
to write using set intersection operators, but it would be possible to
detect some other useful relationships as well.
STREAM-INTERACTIVE-P is definitely a good idea, though I would have called
it INTERACTIVE-STREAM-P for symmetry with INPUT-STREAM-P.
You've got a reference to *STANDARD-ERROR* in there where I think you
want *ERROR-OUTPUT*.
Under "cost to implementors", why do you say all implementations will have
to change? Additions are not traditionally counted as changes. Separate
things out so you don't scare people reading casually. The basic structure
of the streams is not changed by this proposal. The restrictions on what
those streams can be is in fact weakened so that if anything, some
non-conforming implementations might become conforming. Make this two
paragraphs, I think, separating the issue of the stream hierarchy from the
issue of the new streams.
[In fact, I would very much prefer to see this go as two separate
proposals since they're really separable issues. That way, if we get
bogged down in the set of functions operating on streams and that takes
longer to get voted in (or never gets voted in), we'll still have the
important changes to the stream bindings taken care of -- I don't expect
that issue to be nearly so controversial now that this proposal is simplified
as you have it here.]
I'll reserve specific statements of approval until I see a redraft or
replies to these comments. I think it's getting better, though.
∂28-Jun-88 1347 CL-Cleanup-mailer Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88 13:47:49 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426049; Tue 28-Jun-88 16:47:36 EDT
Date: Tue, 28 Jun 88 16:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DOTTED-MACRO-FORMS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: goldman@VAXA.ISI.EDU
References: The message of 14 Jun 88 17:32 EDT from goldman@VAXA.ISI.EDU
Message-ID: <880628164723.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: DOTTED-MACRO-FORMS
References: forms (p54), lists and dotted lists (pp26-27),
DEFMACRO (p145), destructuring macro arguments (p146)
Category: CLARIFICATION
Edit history: 28-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is not explicit about whether macro forms may be dotted lists.
p54 says that only certain forms are "meaningful": self-evaluating
forms, symbols, and "lists".
pp26-27 defines "list" and "dotted list". It goes on to say
``Throughout this manual, unless otherwise specified, it is an
error to pass a dotted list to a function that is specified
to require a list as an argument.''
p146 states that in DEFMACRO destructuring, ``the argument
form that would match the parameter is treated as a
(possibly dotted) list, to be used as an argument forms list
for satisfying the parameters in the embedded lambda list.''
It goes on to say that ". var" is treated like "&rest var"
at any level of the defmacro lambda-list.
Test Case:
#1: (DEFMACRO MACW (&WHOLE W &REST R) `(- ,(CDR W)))
(MACW . 1) => ??
#2: (DEFMACRO MACR (&REST R) `(- ,R))
(MACR . 1) => ??
#3: (DEFMACRO MACX (&WHOLE W) `(- ,(CDR W)))
(MACX . 1)
Current Practice:
A. Some implementations bind W to (MACW . 1) in #1 and #3
and bind R to 1 in #1 and #2.
B. Some implementations bind W to (MACW . 1) in #3
and signal a syntax error in #1 and #2.
C. Some implementations signal a syntax error in #1, #2, and #3.
Symbolics Genera is such an implementation.
Proposal (DOTTED-MACRO-FORMS:EXPLICITLY-VAGUE):
Clarify that it is an error for a macro form to be a dotted list.
Rationale:
Makes current practice explicit.
Dotted lists are a possible symptom of program syntax error.
Allowing implementations to check for this error may catch enough
errors to justify the loss of program flexibility.
Test Case:
(MACW . 1) would be an error under this proposal.
(MACR . 1) would be an error under this proposal.
Cost to Implementors:
None. This is merely a clarification of existing practice.
Cost to Users:
None. Users already can't rely on this behavior since it varies
widely between implementations already.
Proposal (DOTTED-MACRO-FORMS:ALLOW):
Clarify that if &REST occurs in a DEFMACRO lambda-list, it is permitted
to match an atom or dotted list.
Rationale:
This is more flexible, and there is no efficiency or compatibility
argument for not allowing it.
Test Case:
(MACW . 1) would reliably return -1 under this proposal.
(MACR . 1) would reliably return -1 under this proposal.
Cost to Implementors:
Generally trivial. In most cases, some error checking might have to
be removed or the algorithm used by the destructuring bind primitives
might have to be modified slightly.
Cost to Users:
None. Users already can't rely on this behavior since it varies
widely between implementations already.
Cost of Non-Adoption:
Some users would continue to incorrectly believe the behavior
was well-defined, and portability problems would result.
Benefits:
People would know what to expect.
Aesthetics:
Some people believe that dotted forms are ugly. Disallowing dotted forms
would make them happier.
Some people believe that there's no reason to unnecessarily restrict
&WHOLE and/or &REST since there is no computational overhead and since
the interpretation, if there is one at all, is pretty well agreed upon.
Most importantly, however, we should be clear about what we intend or allow.
If this is well-defined, we should say how.
If this is not well-defined, we should say so.
Discussion:
Goldman@VAXA.ISI.EDU raised this issue on Common-Lisp.
Pitman converted Goldman's mail to this formal proposal, but some
parts had to change in the process because of some apparent confusion
in the original message about the number of arguments permitted when
an &WHOLE variable is the only variable in a lambda list. Pitman
believes you must write (&WHOLE W &REST IGNORE) in the case where
Goldman as using just (&WHOLE W).
Goldman's message seemed to suggest we adopt something similar to
DOTTED-MACRO-FORMS:ALLOW.
Pitman supports DOTTED-MACRO-FORMS:EXPLICITLY-VAGUE.
∂28-Jun-88 1353 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-UTILITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88 13:53:52 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426053; Tue 28-Jun-88 16:53:18 EDT
Date: Tue, 28 Jun 88 16:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
To: piazza%lisp.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8806281758.AA10391@decwrl.dec.com>
Message-ID: <880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
You called the proposal SYMBOL-MACROLET:FLUSH rather than
SYMBOL-MACROLET-UTILITY:FLUSH.
I personally oppose this proposal, but I of course have no opposition to
it's being presented to X3J13 for a vote.
This is a very complex issue, and I don't think it does it justice
to have such a terse presentation. I think both the specific reasons
why people dislike it (I believe there to be interesting semantic
arguments which go beyond a desire for a minimalist language)
and the specific reasons why people think it's an important new language
feature need to be brought out.
Issues I'd like to see added at appropriate points (perhaps in the
discussion):
* Current Practice
Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET
macro and compiler support for a SYMBOL-MACROLET special form.
* Abstraction / Expressive Power
Symbolics Cloe originally started with the macro version of
SYMBOL-MACROLET, but found that the problem is that a code-walking
SYMBOL-MACROLET destroys important abstraction information (like the
fact that a particular TAGBODY/GO/BLOCK/RETURN configuration can be
viewed as a PROG/PROG*/DO/DO*/...). There's no loss of computational
power by doing the expansion, but there is a loss of perspicuity and
it is not always easy for a compiler to put that information back in.
* ONCE-ONLY
If I recall correctly, some people have a worry about the relationship
between SYMBOL-MACROLET and ONCE-ONLY (an interesting macro which
occurs in several implementations). I haven't thought hard about this
issue, but maybe someone who has can comment on it.
Note that if users write their own code-walking SYMBOL-MACROLET, the
wrong interaction may happen with a ONCE-ONLY primitive and there's
no obvious way to work around the problem.
* Need by users
I've wanted this feature on a number of occassions to help me implement
embedded languages. I bet others have, too. I think that wants to at
least get mentioned somewhere. When arbitrary users come up with the
need for this facility, it is unreasonable (both in terms of code
duplication and in terms of programmer expertise) to suppose that they
can or should just go out and write a code-walker. Having written one
myself, I must say I think that getting it right for even one
implementation is very hard and making it really portable is almost a
pipe dream.
I think there other issues lurking here as well, but these should do as
starters to help flesh out this proposal.
∂28-Jun-88 1413 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Jun 88 14:13:36 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426076; Tue 28-Jun-88 17:11:54 EDT
Date: Tue, 28 Jun 88 17:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: vanroggen%aitg.decnet@Hudson.DEC.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 28 Jun 88 12:47 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880628171141.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 28 Jun 88 12:47:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Could you specify the "technicality" referred to in the CURRENT PRACTICE
section (or leave out the argument)?
...
CLtL specifies that "all" of the functions, macros, variables, etc. it
describes must be in the LISP package, but it doesn't say "all and
only". There's technically nothing keeping any implementation from
defining any of the variables as a function or macro, or any of the
functions as a variable. Indeed, it doesn't say that other things can't
occur in the package besides those things described.
On my list of things to submit is a cleanup item clarifying this point.
I'll expand it in the next draft if it seems possible to do so concisely,
or perhaps move the remark to the discussion.
I just wanted to indicate somewhere that implementations like Symbolics
Genera which offer a LAMBDA macro are technically in conformance with
CLtL. I could do that in the discussion section, for example.
∂29-Jun-88 0931 CL-Cleanup-mailer
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88 09:31:52 PDT
Date: 29 Jun 88 12:27:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Although VAX LISP happens to conform to DOTTED-MACRO-FORMS:ALLOW, I
think making dotted macro forms be an error is the right thing to do.
It's best to avoid blurring the data/code distinction too much, particularly
for people who are new to Lisp.
---Walter
------
∂29-Jun-88 1013 CL-Cleanup-mailer
Received: from hudson.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88 10:13:03 PDT
Date: 29 Jun 88 13:04:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
To: "cl-cleanup" <cl-cleanup@sail.stanford.edu>
Reply-To: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
What's the name of this issue? STANDARD-OUTPUT-xxx or STANDARD-INPUT-xxx?
The problem description and proposal sound pretty good, except that I
don't understand the reason for the restriction that the predefined
streams other than *TERMINAL-IO* can't be synonym streams for each other.
Is it really necessary to disallow some implementation initially binding
*ERROR-OUTPUT* to a synonym stream for *DEBUG-IO*, for example?
I don't see the need for adding three more predicates. Where is the
justification? Most of the other sections of the proposal adequately
justify the need for loosening the initial binding requirements for
predefined streams, but not for the additional predicates.
Furthermore the descriptions of those predicates seem controversial.
What is STREAM-INTERACTIVE-P really trying to establish? It seems
unlikely that output to a stream satisfying the predicate will really
change the following input--there aren't any such streams in Common
Lisp now, are there? Or is it really trying to ask if there's someone
out there (human or not) that will provide (synchronously?) some input
after there's been some output? Or is something like TWO-WAY-STREAM-P
sufficient? Does this imply *TERMINAL-IO* must be a TWO-WAY-STREAM?
Or is it just asking if it's bidirectional?
I assume the use of *STANDARD-ERROR* is a typo in the Test Case.
---Walter
------
∂29-Jun-88 1054 CL-Cleanup-mailer RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Jun 88 10:54:30 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA11621; Wed, 29 Jun 88 10:54:12 PDT
Date: Wed, 29 Jun 88 10:54:12 PDT
Message-Id: <8806291754.AA11621@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: DECWRL::KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
> You called the proposal SYMBOL-MACROLET:FLUSH rather than
> SYMBOL-MACROLET-UTILITY:FLUSH.
Oops.
> Symbolics Cloe has both a code-walking version of a SYMBOL-MACROLET
> macro and compiler support for a SYMBOL-MACROLET special form.
I'll add this to current practice.
> * Abstraction / Expressive Power
>
> Symbolics Cloe originally started with the macro version of
> SYMBOL-MACROLET, but found that the problem is that a code-walking
> SYMBOL-MACROLET destroys important abstraction information (like the
> fact that a particular TAGBODY/GO/BLOCK/RETURN configuration can be
> viewed as a PROG/PROG*/DO/DO*/...). There's no loss of computational
> power by doing the expansion, but there is a loss of perspicuity and
> it is not always easy for a compiler to put that information back in.
This seems to have to do with whether SYMBOL-MACROLET should be a macro or a
special form. I've written (but not yet distributed) a separate issue for
this, but I'd like to first see debate on the keep/flush question. Note that,
as voted, CLOS specifies SYMBOL-MACROLET to be a macro, which implies code
walking.
> * ONCE-ONLY
>
> If I recall correctly, some people have a worry about the relationship
> between SYMBOL-MACROLET and ONCE-ONLY (an interesting macro which
> occurs in several implementations). I haven't thought hard about this
> issue, but maybe someone who has can comment on it.
>
> Note that if users write their own code-walking SYMBOL-MACROLET, the
> wrong interaction may happen with a ONCE-ONLY primitive and there's
> no obvious way to work around the problem.
Again, this is a code-walking-vs.-special-form issue. I agree that, if
admitted to the language, SYMBOL-MACROLET should be a special form, not a
macro. However, I also believe that that's a different question.
> * Need by users
>
> I've wanted this feature on a number of occassions to help me implement
> embedded languages. I bet others have, too. I think that wants to at
> least get mentioned somewhere. When arbitrary users come up with the
> need for this facility, it is unreasonable (both in terms of code
> duplication and in terms of programmer expertise) to suppose that they
> can or should just go out and write a code-walker. Having written one
> myself, I must say I think that getting it right for even one
> implementation is very hard and making it really portable is almost a
> pipe dream.
I'll include a mention about "embedded languages." Of course, embedded
languages are not Common Lisp. If one favors SYMBOL-MACROLET because it
supports embedded languages, then one "should" also favor souping up
readmacros to make READ a fully-general parser, for how else can we support
an embedded language like FORTRAN?
/JEP
∂29-Jun-88 1114 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Jun 88 11:14:15 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 426591; Wed 29-Jun-88 14:12:03 EDT
Date: Wed, 29 Jun 88 14:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
To: vanroggen%aitg.decnet@hudson.dec.com
cc: cl-cleanup@sail.stanford.edu, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: The message of 29 Jun 88 13:04 EDT from "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
Message-ID: <880629141141.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 Jun 88 13:04:00 EDT
From: "AITG::VANROGGEN" <vanroggen%aitg.decnet@hudson.dec.com>
... I don't understand the reason for the restriction that the predefined
streams other than *TERMINAL-IO* can't be synonym streams for each other.
Is it really necessary to disallow some implementation initially binding
*ERROR-OUTPUT* to a synonym stream for *DEBUG-IO*, for example?
I believe it is. People write programs that do things like:
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
but if *DEBUG-IO* is a synonym stream for a two-way stream which is made
up of synonym streams to *STANDARD-INPUT* and *STANDARD-OUTPUT*, then you
get a circular stream and massive lossage results.
Once the STREAM-CLASS-ACCESS issue goes through and it is possible to detect
a synonym stream, it will finally be possible to at least write cautious
code, but I would hate to think that every time I bound one of these streams
to another, that I must first check to make sure that a synonym circularity
is not being introduced.
As I recall, the current wording neither precludes synonym streams to two-way
streams which are synonym streams nor does it preclude later bindings of these
streams in ways that might introduce circularities, so I agree that the intent
of that text might want to be clarified.
Fyi, I've been screwed rather badly by doing the following seemingly harmless
thing:
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
on some implementations only to find out that *TERMINAL-IO* was implemented
as a two-way stream to synonym streams to *STANDARD-INPUT* and
*STANDARD-OUTPUT*. The fireworks that result can be quite messy...
I don't see the need for adding three more predicates...
Heh,heh. This is why I suggested this should be two proposals, Dan.
Furthermore the descriptions of those predicates seem controversial.
What is STREAM-INTERACTIVE-P really trying to establish? ...
These are good points that I think should get nailed down. Among other things
to add to the list of things interactiveness might want to include are:
* Should I prompt for input?
* Is input editing (ie, rubout handling) something that should
be dealt with?
* Should I expect that READ-CHAR might hang waiting for input
(vs returning an eof if no chars are available).
∂29-Jun-88 1116 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jun 88 11:16:27 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA12398; Wed, 29 Jun 88 14:14:06 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA11107; Wed, 29 Jun 88 14:18:05 EDT
Message-Id: <8806291818.AA11107@mist.UUCP>
To: "piazza%lisp.DEC@decwrl.dec.com"@multimax (Jeffrey Piazza)
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue: SYMBOL-MACROLET-UTILITY (Version 1)
In-Reply-To: Your message of Wed, 29 Jun 88 10:54:12 -0700.
<8806291754.AA11621@decwrl.dec.com>
Date: Wed, 29 Jun 88 14:17:58 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I'll include a mention about "embedded languages." Of course, embedded
languages are not Common Lisp. If one favors SYMBOL-MACROLET because it
supports embedded languages, then one "should" also favor souping up
readmacros to make READ a fully-general parser, for how else can we support
an embedded language like FORTRAN?
Embedding languages in Lisp is old and valuable tradition. Therefore
it is reasonable to support a Lisp feature on the grounds that it
makes it easier to use Lisp in one of its traditional areas of
strength.
I would expect to support a language like FORTRAN or C by using READ
as a lexer and writing a separate parser. For example, a Lisp version
of yacc *may* be appearing as free software soon (not from me). I
assume that Kent was refering to custom embedded languages more on the
level of CLISP.
∂29-Jun-88 1136 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jun 88 11:35:43 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA12718; Wed, 29 Jun 88 14:33:28 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA11220; Wed, 29 Jun 88 14:37:26 EDT
Message-Id: <8806291837.AA11220@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (Version 5)
In-Reply-To: Your message of Wed, 29 Jun 88 14:11:00 -0400.
<880629141141.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 29 Jun 88 14:37:21 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
As I recall, the current wording neither precludes synonym streams
to two-way streams which are synonym streams nor does it preclude
later bindings of these streams in ways that might introduce
circularities, so I agree that the intent of that text might want
to be clarified.
I'll try to clean this up. The intent is that the streams in question
can all be synonyms for the same internal stream, but not for each
other, two-way-streams for each other, etc.
I don't see the need for adding three more predicates...
Heh,heh. This is why I suggested this should be two proposals, Dan.
I thought this might happen, but decided to wait and see. The next
version will have two proposals if that's what people want. If anyone
strongly opposes two proposals, speak now or...
Furthermore the descriptions of those predicates seem controversial.
What is STREAM-INTERACTIVE-P really trying to establish? ...
These are good points that I think should get nailed down. Among
other things to add to the list of things interactiveness might
want to include are:
* Should I prompt for input?
* Is input editing (ie, rubout handling) something that should
be dealt with?
* Should I expect that READ-CHAR might hang waiting for input
(vs returning an eof if no chars are available).
Good questions. I'll really rework this one. I thinks that
STREAM-INTERACTIVE-P is the shakiest of the new predicates just
because it's the hardest to nail down.
∂29-Jun-88 1413 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-UTILITY
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jun 88 14:13:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 29 JUN 88 13:46:28 PDT
Date: Wed, 29 Jun 88 13:44 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROLET-UTILITY
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-2.text.newest
In-Reply-To: <8806281758.AA10391@decwrl.dec.com>
Message-ID: <19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Tue, 28 Jun 88 10:58:00 PDT
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Status: DRAFT
Issue: SYMBOL-MACROLET-UTILITY
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f., 2-88f., 2-92f.
Category: DELETION
Edit history: 21-Jun-88, Version 1 by Piazza
Problem Description:
Anything expressible with SYMBOL-MACROLET could also be written with
regular MACROLET, except that the macro symbol could not stand alone as an
expression; it would have to be enclosed in parentheses. The cost
associated with implementing and maintaining the SYMBOL-MACROLET feature
exceeds this incremental utility.
This isn't a problem description, it is a statement of opinion. A
problem description would say something like:
The symbol-macrolet utitily introduced with CLOS has some semantic
problems. <discussion of these problems here>. These problems may
cause problems with some existing code <extension of previous
discussion here>.
Proposal (SYMBOL-MACROLET:FLUSH):
Remove SYMBOL-MACROLET (and WITH-ACCESSORS and WITH-SLOTS) from 88-002R.
Rationale:
Flushing SYMBOL-MACROLET eliminates the cost of implementing and
maintaining this feature, while MACROLET still provides most of
SYMBOL-MACROLET's expressive power.
The explanation of the hack of using the symbol as what looks like a
no arguments function should be presented here. There needs to be a
discussion of the fact that this would work much better in a Lisp-1
than a Lisp-2.
------------------------------------------------------------------------------
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R.
Cost to Implementors:
Presumably few implementors have implemented SYMBOL-MACROLET, excepting
the implementation provided by PCL. If it is flushed from the language,
no one will incur any implementation cost.
Cost to Users:
Users will lose the expressive ability provided by SYMBOL-MACROLET,
WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with
MACROLET.
Another cost is that they won't be able to overload names to mean both
a real function and one of these hack macros. For example:
(defclass foo () (car cdr))
(defun describe-foo (foo)
(macrolet ((car () (slot-value foo 'car))
(cdr () (slot-value foo 'cdr)))
...
Can't use normal car and cdr in here
...))
Of course this is something that Scheme programmers are used to dealing
with. But Common Lisp programmers are not. The potential for this
seriously aggravating the existing problem with macro expansions
capturing the wrong lexical context is huge.
Cost of Non-Adoption:
Implementors must implement significant new functionality, adding to
system size and language complexity. (A separate proposal,
SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
specified semantics of SYMBOL-MACROLET.)
I am not sure I buy this. For one, there is already an implementation
of it in PCL. For another, any exiting compiler must already have the
right stuff in it to do this.
If you insist on doing an entirely custom CLOS, the work required to do
this part of it is very small compared to the work required to do the
rest of it.
Benefits:
SYMBOL-MACROLET:FLUSH reduces the implementation and maintenance costs for
a Common Lisp implementation. It also simplifies the language by
eliminating the concept of a "symbol macro."
Aesthetics:
There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
as a construct in the language. Some feel it hairs up the language while
offering only trivial benefit beyond what is already provided through
normal macros. Others herald it as a important new language feature.
Discussion:
As it was adopted by X3J13 as part of CLOS, there has been no formal
discussion on the pros and cons SYMBOL-MACROLET on its own.
That discussion should appear in this part of the proposal.
-------
∂29-Jun-88 2336 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Jun 88 23:36:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 29 JUN 88 23:33:15 PDT
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:32:43 PDT
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Mon, 27 Jun 88
10:48 EDT, <880627104822.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880629-233315-4002@Xerox>
How 'bout just making it explicit that this things are intentionally left
undefined, with some of the reasons you gave?
I'm a little leary of adding a function where the requirements on the output
values are not spelled out. Is the width of "froboznick" guaranteed to be the
sum of the widths of "frob" and "oznick"? Greater than the width of "frob"? Of
"foo"? What about kerning?
If we can't guarantee anything about these functions, can programmers really
write portable programs? Or would a hack with #+ and #- be more honest?
∂30-Jun-88 0004 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88 00:04:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 29 JUN 88 23:56:06 PDT
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:55:32 PDT
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: edsel!jlm@labrea.stanford.edu's message of Mon, 27 Jun 88 12:29:15
PDT, <8806271929.AA00551@bhopal.lucid.com>
To: Jim McDonald <edsel!jlm@labrea.stanford.edu>
cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
Message-ID: <880629-235606-4020@Xerox>
I'd rather see a portable implementation circulated, frankly.
Why should these be in the standard?
∂30-Jun-88 0623 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Jun 88 06:23:38 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA18500; Thu, 30 Jun 88 06:23:24 PDT
Date: Thu, 30 Jun 88 06:23:24 PDT
Message-Id: <8806301323.AA18500@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:55:32 PDT
I'd rather see a portable implementation circulated, frankly.
Why should these be in the standard?
To allow and encourage compiler optimizations that would otherwise
be difficult to do.
---Walter
∂30-Jun-88 0735 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jun 88 07:35:14 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 427060; Thu 30-Jun-88 10:34:33 EDT
Date: Thu, 30 Jun 88 10:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-INFO (Version 4)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
Dick@WHEATIES.AI.MIT.EDU
In-Reply-To: <880629-233315-4002@Xerox>
Message-ID: <880630103421.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: 29 Jun 88 23:32:43 PDT
From: masinter.pa@Xerox.COM
How 'bout just making it explicit that this things are intentionally left
undefined, with some of the reasons you gave?
I'm a little leary of adding a function where the requirements on the output
values are not spelled out. Is the width of "froboznick" guaranteed to be the
sum of the widths of "frob" and "oznick"? Greater than the width of "frob"? Of
"foo"? What about kerning?
Dick spelled out the requirement. He doesn't need an algebra on these values.
The only need he has, and it's quite legitimate, is to ask "If I were to output
this, where would I end up." If there's something that will, in the same units,
tell him where the margin is, he can at least know if he's passing an interesting
boundary.
Kerning is not really relevant. Either the implementation looks at kerning when
deciding if a line is too long or it doesn't. The thing which returns the margin
position and the thing which returns the string width can easily conspire to do
the right thing without prejudice to whether kerning is involved.
Dick could have just as well asked for a primitive that would have said
(OUTPUT-FITS-P string stream) and returns T or NIL saying whether the string will
fit on the stream without running into the margin, but that would have been so
limited to his application that it would have served no useful extension purposes
in implementations that did want to extend it.
If we can't guarantee anything about these functions, can programmers really
write portable programs? Or would a hack with #+ and #- be more honest?
The issue is not honesty. The issue is one of codifying existing
practice. Dick Waters has done a lot of really interesting work on
pretty printers over the years. That work has been of tremendous benefit
to the Lisp community. In Maclisp, he could essentially tell where the
end of the line was. We took away that capability in Common Lisp. In
Common Lisp, you can't even clear the screen. I personally think that
was ridulous, and I'm surprised that the user community put up with it.
But the world was more complicated with fancy displays and fancy fonts
and all, and people were tolerant for a while.
But we've had our time to play and it's really time we came up with
something useful so people can get on with their work if at all
possible. The set of primitives proposed is a subset of what is in use
on a major Lisp workstation and it has been demonstrated to be useful.
If it has problems to do with kerning (things have to be rounded off),
output will look no stupider than it will look if we don't allow people
to have pretty printed output at all. More likely, it will work just
fine because most applications are very fault tolerant -- in the worst
case, you might get some line wraparound and yucky looking typeout. But
you'll get line wraparound a LOT more in portable programs if you offer
people no way at all to detect the edge of the line. We should just warn
people that the process is heuristic and people who are building weapons
systems or real time medical systems can avoid using it.
Common Lisp is not an exercise in doing everything right the first time.
It is an exercise in trying to satisfy the commercial needs of a lot of
Lisp users for the next few years. My condition system has its problems,
too, but the important point in both cases is that it is an improvement
over what is there if you don't have it. Sometimes when you don't fully
understand an issue, you just have to go with your best guess and be
prepared to have problems result. As embarrassing as it is to have your
mistakes noticed later, it's sometimes better than not taking any action
at all. And after using for a few years, you'll have a user community
who can make informed decisions about whether they like what they got
and what they want next. If you don't offer them anything at all, then
in five more years you'll have no one who's any more informed on the
issues than you have now and you'll end up having to make the same
arbitrary decision as you're making now.
Also, this problem is not like characters or pathnames where we are
forcing a representation. If necessary, a particular vendor with special
needs can have these primitives can work completely independently of how
the rest of system represents width, position, etc. on the screen -- or
it can just return NIL all over the place saying it's not willing to
play the game.
∂30-Jun-88 0803 CL-Cleanup-mailer EQUAL
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 30 Jun 88 08:03:23 PDT
Received: by labrea.stanford.edu; Thu, 30 Jun 88 08:03:22 PDT
Received: from bhopal.lucid.com by edsel id AA14691g; Wed, 29 Jun 88 18:44:42 PDT
Received: by bhopal id AA15550g; Wed, 29 Jun 88 18:50:58 PDT
Date: Wed, 29 Jun 88 18:50:58 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806300150.AA15550@bhopal.lucid.com>
To: edsel!jlm@labrea.stanford.edu
Cc: common-lisp@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 24 Jun 88 16:40:01 EST <8806242339.AA18154@bhopal.lucid.com>
Subject: EQUAL
Date: Fri, 24 Jun 88 16:40:01 EST
From: Jim McDonald <jlm>
My concern about having EQUAL descend structures and arrays is that
they are much more likely than lists to be circular.
...
As a rule of thumb, I'd bet that less than .0001% of all lists are
circular, and that less than 1% of all arrays are circular, but only
that less than 30% of all structures are circular.
Probabilities can be very misleading here -- for any given application,
the probability is typically either 0 or 1. And even for those cases
that do utilize circular stucture (I'm including lists here), the
relevance to the EQUAL question is entirely moot if they are never
given as arguments to EQUAL. One would surely suspect that to be the
case for the many programs that deal in circular lists!
-- JonL --
∂30-Jun-88 0809 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Jun 88 08:09:10 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 427086; Thu 30-Jun-88 11:08:20 EDT
Date: Thu, 30 Jun 88 11:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
To: Masinter.PA@Xerox.COM, vanroggen%aitg.DEC@decwrl.dec.com,
piazza%lisp.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8806301323.AA18500@decwrl.dec.com>,
The message of 29 Jun 88 23:55 PDT from masinter.pa@Xerox.COM,
<8806291754.AA11621@decwrl.dec.com>
Message-ID: <880630110812.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Thu, 30 Jun 88 06:23:24 PDT
From: vanroggen%aitg.DEC@decwrl.dec.com
From: masinter.pa@Xerox.COM
Date: 29 Jun 88 23:55:32 PDT
I'd rather see a portable implementation circulated, frankly.
Why should these be in the standard?
To allow and encourage compiler optimizations that would otherwise
be difficult to do.
Right. These are easy to write correctly in a portable way, but the
portable way is not nearly as efficient as what coudl be non-portably
provided... And I doubt anyone would spend any effort to optimize them
if they weren't part of the core language.
But as alluded to in the proposal, this would also get us a foothold
from which to be able to suggest flushing the -IF-NOT functions and
:TEST-NOT keywords. Those functions provide not only clutter in the
form of size, but it's a pain to try to coherently explain
- the default value of the :TEST and :TEST-NOT parameters, which
cannot be independent
- the effect of providing both the :TEST and :TEST-NOT
I'll be submitting a proposal to make that cleanup, and that proposal
might fly on its own, but it would go better (I think) if it had support
from a reasonably concise alternative mechanism (particularly COMPLEMENT).
Also, I bet the reason there are not :TEST-AND and :TEST-OR arguments
is not that ANDing and ORing predicates is less useful than NOTing them,
but rather that NOT takes one argument and the rest take more and no one
wanted to worry about :TEST-AND '(FOO BAR) or :TEST-AND (LIST #'FOO #'BAR)
which would have had to cons a needless list. This proposal provides a
way to specify things so that no consing is necessary in many cases
-- :TEST (CONJOIN #'FOO #'BAR) -- Stack consing might occur, or inlining
might completely unroll the need for a list at all...
Aside to Jeffrey, I like COMMUTE as an addition to the set of things I
had listed, by the way, but I didn't really like PERMUTE as described.
It is a nice idea conceptually but the fact that its permuation argument
is evaluated means that it can be opaque to such optimization when the
argument is not constant, and the result may be suprisingly less
efficient than the programmer may expect in those cases.
∂30-Jun-88 0927 CL-Cleanup-mailer various DEFSTRUCT issues
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88 09:26:34 PDT
Return-Path: <barmar@Think.COM>
Received: from brigit.think.com by Think.COM; Thu, 30 Jun 88 12:24:23 EDT
Received: from OCCAM.THINK.COM by brigit.think.com; Thu, 30 Jun 88 00:12:59 EDT
Date: Thu, 30 Jun 88 00:10 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: various DEFSTRUCT issues
To: cl-cleanup@sail.stanford.edu
Message-Id: <19880630041044.9.BARMAR@OCCAM.THINK.COM>
At the X3J13 meeting there was an issue about DEFSTRUCT and duplicated
slot names. This has caused me to think a bit about some other related
problems with DEFSTRUCT. I haven't really given a whole lot of thought
to these, but I wanted to get them out to some other people before I
forgot.
Issue 1: Slots with STRING-EQUAL names
This is the one that I briefly mentioned at the meeting. Consider the
following:
(in-package 'foo)
(defstruct struct
slot1
bar:slot1)
The problem with this is that the package of the slot name is generally
not used by DEFSTRUCT. The constructor takes keyword arguments, so it
would be ambiguous which slot is being initialized by (make-struct
:slot1 <val>). And accessor functions are interned in the package that
is current when the DEFSTRUCT is being expanded, so it would try to
define FOO::STRUCT-SLOT1 as an accessor for both slots.
In the case of a single structure definition, like above, it would
probably be OK to specify that string-equal slot names are not
permitted. However, they are more likely to occur when :INCLUDEing a
structure in a different package:
(in-package 'foo)
(defstruct foo-struct
slot1)
and in a different file:
(in-package 'bar)
(defstruct (bar-struct (:include foo:foo-struct))
slot1)
In this case you don't have a problem with the accessors, because they
are FOO::FOO-STRUCT-SLOT1 and BAR::BAR-STRUCT-SLOT1. However, you still
have a problem with MAKE-BAR-STRUCT, because of the keyword argument.
I think the solution to this is to make use of the extension to keyword
argument syntax that was done for CLOS. The keyword arguments to
structure constructors would be the actual name of the argument.
However, for back compatibility, we can also specify that :keywords are
also accepted (but we should deprecate this use). However, it is an error
to use the :keyword version if the structure contains two string-equal
slot names.
Additionally, the specification of the default printed representation of
structures must be tightened, as it currently allows the slot names to
be printed in any package. They should be printed with their correct
package prefixes.
Existing practice: Sun Common Lisp 2.0.3 (Lucid, I believe) detects
attempts to define structures with string-equal slots at defstruct
expansion time, whether the conflicting slot comes from inheritance or
not. Symbolics Common Lisp in Genera 7.2 and Kyoto Common Lisp June 3,
1987 don't notice the conflict. In SCL, (make-bar-struct :slot1 <val>)
creates a structure in which both slots contain <val>); in KCL, the
FOO::SLOT1 slot contains VAL, while the BAR::SLOT1 slot contains NIL.
Regarding printed reps, Symbolics currently prints all the slot names as
:keywords; KCL simply PRIN1's the slot name symbols, so it corresponds
to my proposal; Sun CL uses no package prefixes at all.
Issue 2: Redefining structures
CLOS specifies in greate detail what happens when classes are redefined.
What happens when structures are redefined? Does CLtL discuss this
anywhere? Assuming existing practice is what I think it is, we should
probably specify that it is an error to use a structure accessor or
copier on a structure that was created prior to the redefinition; this
may imply that it is an error to try to print such a structure, as the
print function might use an accessor.
But what about redefining :INCLUDEd structures? What does this do:
(defstruct foo
a b)
(defstruct (bar (:include foo))
c)
(defstruct foo
b a d)
How does this redefinition of FOO affect the BAR structure? In the very
least, I think my above statement should be taken to imply that any BARs
created before FOO is redefined are no longer accessible using the FOO-
accessors. But what about new structures created by MAKE-BAR after the
redefinition? In all three implementations I tried, the redefinition
had absolutely no effect on MAKE-BAR, nor on the printing of BAR
structures. The only anomoly is that (foo-b (make-bar :a 1 :b 2)) now
returns 1; all three apparently implement structures internally as
vectors, and accessors are simply AREFs. One could imagine, however, an
implementation that used property lists or alists internally, so that
FOO-B would continue to return the B slot of BAR structures.
So, we could say that after redefining a structure, it is an error to
use any of its accessors on structures that :INCLUDE that structure but
which have not been reevaluated/recompiled. (Actually, that wording is
pretty attrocious.) And after the :INCLUDEing structure is redefined,
the :INCLUDEe's accessors may only be used on new instances.
barmar
∂30-Jun-88 1145 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 30 Jun 88 11:45:12 PDT
Received: by rice-chex.ai.mit.edu; Thu, 30 Jun 88 14:47:06 EDT
Date: Thu, 30 Jun 88 14:47:06 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8806301847.AA07038@rice-chex.ai.mit.edu>
To: masinter.pa@xerox.com
In-Reply-To: masinter.pa@xerox.com's message of 29 Jun 88 23:32:43 PDT <880629-233315-4002@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
Cc: dick@wheaties.ai.mit.edu, CL-Cleanup@sail.stanford.edu
How 'bout just making it explicit that these things are intentionally left
undefined, with some of the reasons you gave?
I'm a little leary of adding a function where the requirements on
the output values are not spelled out. Is the width of "froboznick"
guaranteed to be the sum of the widths of "frob" and "oznick"?
Greater than the width of "frob"? Of "foo"? What about kerning?
I think that there are some very specific things that we can say. The
key thing is that we have to make it clear exactly what is being
specified. In particular, the actual numerical values are
implementation specific and do not matter much. However, there are
several key RELATIVE properties which are the whole point.
In the following, suppose that N is a positive integer, X and Y are
strings, and S is a stream that fully supports all four functions
OUTPUT-WIDTH, OUTPUT-POSITION, STRING-WIDTH, OUTPUT-SPACE; i.e., NIL is
never returned when any of these functions is called on S.
First, there are three minimal properties of OUTPUT-POSITION.
(1) (NOT (MINUSP (OUTPUT-POSITION S)))
(2) (ZEROP (OUTPUT-POSITION (PROGN (TERPRI S) S)))
(3) If something is at an output position of N on one line, and
something else is at an output position of N on another line, and
assuming that wraparound truncation etc. have not occured on either
line (see (5) below), then the two things are lined up vertically one
under the other.
Second, there are two properties that define
STRING-WIDTH and OUTPUT-SPACE in terms of OUTPUT-POSITION.
(3) (= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
(OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))
(4) (= (+ (OUTPUT-POSITION S) N)
(OUTPUT-POSITION (PROGN (OUTPUT-SPACE N S) S)))
and OUTPUT-SPACE has no effect on S other than introducing blank space
that changes the output position.
For the following properties it must be assumed that X and Y consist
solely of standard characters as defined on CLTL pp20-21 and that X
and Y do not contain any #\newline characters.
The following property defines the meaning of OUTPUT-WIDTH.
(5) Assuming that one has just done (TERPRI S),
If (< (STRING-WIDTH X S) (OUTPUT-WIDTH S))
then (WRITE-STRING X S) is guaranteed to output the string on one line
without any truncation or wraparound.
[If the condition above is not satisfied, then the exact result of
the output is not specified. However, It is assumed that each
implementation will do something reasonable, e.g., use wraparound. It
might also be the case that the output width was pessimistic and that
the string might fit on the end of the line. The point of
OUTPUT-WIDTH is that it returns a guaranteed safe width.]
This property must hold no matter what characters are in X as long
as none of these characters cause a reduction in output position.
I.e., it is alright for X to contain tabs and many other weird
characters, but the property may be violated if X contains newlines or
backspaces.
(6) (= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
(+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))
This property is violated for many kinds of nonstandard characters,
notably tabs and newlines. It could also fail if the strings had
ligatures or font change characters or other wierd things.
Nevertheless, this property is very useful. The efficiency of my
pretty printer is significantly improved by assuming that this
property holds.
Dick Waters
PS I agree with KMPs basic comment that although this is indeed a
fuzzy area, it is better to get information which may in many
situations only be approximate than not to be able to get any
information at all.
∂30-Jun-88 1557 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88 15:57:46 PDT
Received: from Burger.ms by ArpaGateway.ms ; 30 JUN 88 15:57:23 PDT
From: masinter.pa@Xerox.COM
Date: 30 Jun 88 15:56:48 PDT
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: KMP@STONY-BROOK.SCRC.Symbolics.COM's message of Thu, 30 Jun 88
10:34 EDT, <880630103421.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU,
Dick@WHEATIES.AI.MIT.EDU
Message-ID: <880630-155723-5604@Xerox>
I guess I wasn't clear. I understand your point, and see that it is probably not
a good idea to be more explicit about what the functions you propose should do.
However, I think the proposal needs to be really explicit that there are no such
contracts, lest users mistakenly assume there are.
∂30-Jun-88 1557 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Jun 88 15:57:41 PDT
Received: from Burger.ms by ArpaGateway.ms ; 30 JUN 88 15:51:33 PDT
From: masinter.pa@Xerox.COM
Date: 30 Jun 88 15:48:42 PDT
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Thu, 30 Jun 88
06:23:24 PDT, <8806301323.AA18500@decwrl.dec.com>
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880630-155133-5578@Xerox>
Perhaps you could indicate the kinds of compiler optimizations that might be
useful? Would people use these functions if the compiler didn't optimize them?
Souldn'sShouldn't the mythical compiler be able to do as well given
INLINE-proclaimed portable definitions?
∂01-Jul-88 0701 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Jul 88 07:01:11 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Fri, 1 Jul 88 10:00:24 EDT
Received: by brigit.think.com; Fri, 1 Jul 88 09:59:34 EDT
Date: Fri, 1 Jul 88 09:59:34 EDT
From: gls@Think.COM
Message-Id: <8807011359.AA10552@brigit.think.com>
To: dick@wheaties.ai.mit.edu
Cc: masinter.pa@xerox.com, dick@wheaties.ai.mit.edu,
CL-Cleanup@sail.stanford.edu
In-Reply-To: Richard C. Waters's message of Thu, 30 Jun 88 14:47:06 EDT <8806301847.AA07038@rice-chex.ai.mit.edu>
Subject: Issue: STREAM-INFO (Version 4)
Dick,
Does your pretty printer depend crucially on the equality in
properties (3) and (6), or can they be relaxed to inequalities
(3) (<= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
(OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))
(6) (<= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
(+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))
?
--Guy
∂02-Jul-88 1158 CL-Cleanup-mailer Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jul 88 11:58:08 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 428071; Fri 1-Jul-88 19:57:18 EDT
Date: Fri, 1 Jul 88 19:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PATHNAME-COMPONENT-CASE
References: Pathnames (pp410-413),
MAKE-PATHNAME (p416),
PATHNAME-HOST (p417),
PATHNAME-DEVICE (p417),
PATHNAME-DIRECTORY (p417),
PATHNAME-NAME (p417),
PATHNAME-TYPE (p417)
Category: CHANGE
Edit history: 1-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Issues of case in pathnames are a major source of problems.
In some file systems, the canonical case is lowercase, in some
uppercase, in some mixed.
In some file systems, case matters, in others it does not.
(NAMESTRING (MAKE-PATHNAME :NAME "FOO" :TYPE "LISP"))
will produce an `ugly' file name like "FOO.LISP" in many (but not all)
Common Lisp implementations talking to Unix, for example.
(NAMESTRING (MAKE-PATHNAME :NAME "foo" :TYPE "lisp"))
might produce an `ugly' file name like "↑Vf↑Vo↑Vo.↑Vl↑Vi↑Vs↑Vp"
in a Common Lisp implementation talking to a Tops-20.
Problems like this make it difficult to use MAKE-PATHNAME for much of
anything without corrective (non-portable) code.
Other problems occur in merging because doing
(NAMESTRING (MERGE-PATHNAMES (MAKE-PATHNAME :HOST "MY-TOPS-20" :NAME "FOO")
(PARSE-NAMESTRING "MY-UNIX:x.lisp")))
should probably return "MY-TOPS-20:FOO.LISP" but in fact might return
"MY-TOPS-20:FOO.↑Vl↑Vi↑Vs↑Vp" in some implementations.
Problems like this make it difficult to use any merging primitives for
much of anything without corrective (non-portable code).
Proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE):
Designate a treatment for case in pathname components which is
distinct from the treatment of case in the namestrings. The treatment
should be invariant across operating systems.
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all uppercase, it is said to
designate a name in the system's "canonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is all lowercase, it is said to
designate a name in the system's "anticanonical case".
If a string given to MAKE-PATHNAME, or returned by any of the
PATHNAME-xxx accessor operations, is mixed case, it is said
designate a name in exactly the indicated case.
Functions such as PARSE-NAMESTRING and NAMESTRING which convert
from or to native host syntax will perform any necessary conversions
from internal syntax.
Note: In fact, this proposal does not require an implementation to
change its internal representation. It only requires the CL-defined
accessors to behave as if the internal representation had been changed.
Whether the actual internal representation is changed is still up to an
implementation. A consequence of this is that if pathnames print
in a way that shows the components individually (such as #S), they
are not constrained to print the components in any particular case;
they are constrained only to have definite syntax conventions and to
be able to invert those conventions at the appropriate time. Any change
to the way pathnames print is beyond the scope of this proposal.
Test Case:
(PATHNAME-NAME (PARSE-NAMESTRING "MY-UNIX:/me/foo.lisp")) => "FOO"
(PATHNAME-NAME (PARSE-NAMESTRING "MY-TOPS-20:<ME>FOO.LISP")) => "FOO"
Rationale:
This does not solve the whole pathname problem, but it does improve
the situation for a clearly defined set of very common problems.
Current Practice:
Symbolics Genera implements this behavior.
Cost to Implementors:
While this proposal is compatible with CLtL, it may not be compatible with
the implementations of CLtL which some implementations have chosen.
It is possible to isolate the forced changes to the referenced functions
(MAKE-PATHNAME and the PATHNAME-xxx accessors). Existing functions can be
renamed, and new functions with the same name can be introduced which simply
encapsulate case conversion. No further change is forced.
It may, however, be desirable for an implementation to make a more complete
overhaul of their representation. In implementations where the implementors
feel a need to do this, the amount of work may be considerably greater.
Cost to Users:
Technically, this change is upward compatible.
In fact, since the existing CLtL spec is so poor, nearly everyone relies
heavily on implementation-specific behavior since there is little other
choice. As such, any change is almost certain to break lots of programs,
in usually superficial but nevertheless important ways. However, if we
really make the pathname facility more portable, the user community may be
willing to bear the consequences of these changes.
Cost of Non-Adoption:
We would be contributing to the perpetuation of the existing fiasco of a
pathname system.
Benefits:
The major costs of non-adoption would be avoided.
Aesthetics:
More code is required, but the code supports a simpler user model.
Anything that simplifies the user model of pathnames is going to be an
improvement.
Discussion:
Pitman suports PATHNAME-COMPONENT-CASE:CANONICALIZE.
∂05-Jul-88 0854 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu ([128.52.38.46]) by SAIL.Stanford.EDU with TCP; 5 Jul 88 08:54:07 PDT
Received: by rice-chex.ai.mit.edu; Tue, 5 Jul 88 11:55:44 EDT
Date: Tue, 5 Jul 88 11:55:44 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8807051555.AA03348@rice-chex.ai.mit.edu>
To: gls@think.com
Cc: masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: gls@think.com's message of Fri, 1 Jul 88 09:59:34 EDT <8807011359.AA10552@brigit.think.com>
Subject: Issue: STREAM-INFO (Version 4)
Does your pretty printer depend crucially on the equality in
properties (3) and (6), or can they be relaxed to inequalities
(3) (<= (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
(OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))
Several points here; First, the pretty printer does crucially depend
on the fact that if there is any significant inequality, then it must go
the other way. I.e.
(=> (+ (OUTPUT-POSITION S) (STRING-WIDTH X S))
(OUTPUT-POSITION (PROGN (WRITE-STRING X S) S)))
The pretty printer has to be able to make a guaranteed pesimistic
prediction of what the output position will be without actually
printing anything. If the inequality went the way you suggest, I
could not be sure that printing the string would not go off of the end
of a line.
Second, having it be an equality is not TOTALLY crucial, but without
it, I would have to query the stream for the resulting output position
every time I sent a string to it. With the equality, the stream
almost never has to be queried---A significant saving in time.
Third, it is true however, that it is not going to make any
difference to the pretty printer if the equality is off slightly. The
most aesthetic way for an implementation to deal with this case is to
make the horizontal unit returned by the functions course rather than fine.
Fourth, if there is a fear that the property above would make it too
hard to implement STRING-WIDTH, then one might only require that the
property hold if the string contains standard characters, and allow
implementations to vary as to how close they come to the ideal in
general. (Note that with this weak a restriction, and assuming a
fixed width font, the function STRING-WIDTH could be implemented
merely as LENGTH. This is the way the pretty printer works now, and
it doesn't seem to be causing any problems.)
Fifth, the bottom line here is that pretty printing will work better
or worse based on how accurately STRING-WIDTH is implemented.
However, there is nothing for the pretty printer to do, but simply
assume that the information is accurate.
(6) (<= (STRING-WIDTH (CONCATENATE 'STRING X Y) S)
(+ (STRING-WIDTH X S) (STRING-WIDTH Y S)))
Here, the comments are much the same.
First, this time the inequality as stated is in the proper direction.
Second, having the inequality is not totally crucial, but it
significantly reduces the number of times OUTPUT-POSITION and/or
STRING-LENGTH have to be called.
Third, it is not going to make any difference to the pretty printer
if the equality is off slightly.
Fourth, note that the equality is only required when the string
contains standard characters. If a fixed width font is in use, this
is consistent with implementing STRING-WIDTH as length.
I strongly suggest supporting both of the above as eqaulities at least
for standard characters. Since in the fixed width font case this is
trivial to do, I see no argument against it.
Dick
∂05-Jul-88 1156 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Jul 88 11:56:38 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 428605; Tue 5-Jul-88 14:56:20 EDT
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: pierson%mist@MULTIMAX.ARPA, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Dan -- I know you were gonna do something on this. I wasn't sure what
your timeframe was. It's very important to us right now, though, so in
an effort to get something on the table, I wrote the following. I hope
this doesn't step on your toes, but rather makes your job a bit easier.
-kmp
-----
Issue: PATHNAME-SUBDIRECTORY-LIST
References: Pathnames (pp410-413), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417)
Category: CHANGE
Edit history: 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM
05-Jul-88, Version 2 by Pitman (major revision)
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
It is impossible to write portable code that can produce a pathname
in a subdirectory of a hierarchical file system. This defeats much of
the purpose of having an abstraction like pathname.
According to CLtL, only a string is a portable filler of the directory
slot, but in order to denote a subdirectory, the use of separators (such
as dots, slashes, or backslashes) would be necessary. The very fact that
such syntax varies from host to host means that although the
representation might be "portable", the code using that representation
is not portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
Related problems:
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory
of "FOO" while in other implementations because "." is not the
separator. To be safe, portable programs must avoid all potential
separators.
- Even in implementations where "." is the separator, "FOO.BAR" may be
recognized by some to mean the "BAR" subdirectory of "FOO" and by others
to mean `a seven letter directory with "." being a superquoted part of
its name'.
- In fact, CLtL does not even say for toplevel directories whether the
directory delimiters are a part. eg, is "foo" or "/foo" the directory
filler for a unix pathname "/foo/bar.lisp". Similarly, is "[FOO]" or
"FOO" the directory filler for a VMS pathname "[FOO]ME.LSP"?
Proposal (PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION)
Allow a list to be a filler of a pathname. The car of the list may be either
of the symbols :ABSOLUTE or :RELATIVE.
If the car of the list is :RELATIVE, the rest of the list is the
implementation-dependent result of PARSE-NAMESTRING for file systems which
have relative pathnames. Unless some other proposal is submitted to clarify
the behavior of relative pathnames in merging, etc. that behavior is left
undefined.
If the car of the list is :ABSOLUTE, the rest of the list is a list of
strings each naming a single level of directory structure. The strings
should contain only the directory names themselves -- no separator
characters.
The spec (:ABSOLUTE) represents the root directory.
Clarify that if a string is used as a filler of a directory field in a
pathname, it should be the unadorned name of a toplevel directory.
Specifying a string, str, is equivalent to specifying the list
(:ABSOLUTE str).
In place of a string, at any point in the list, the symbol :WILD or
:WILD-INFERIORS may occur. These symbols may not be meaningful for all
operating systems, but may be useful on those operating systems which
do provide such mechanisms. They denote a full wildcard match of one
or several directory levels, respectively.
Test Case:
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "[FOO.BAR]BAZ.LSP")) ;on VMS
=> (:ABSOLUTE "FOO" "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING "/foo/bar/baz.lisp")) ;on Unix
=> (:ABSOLUTE "foo" "bar")
or (:ABSOLUTE "FOO" "BAR") ;if PATHNAME-COMPONENT-CASE:CANONICALIZE passes
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>**>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
Rationale:
This would allow programs to usefully deal with hierarchical file systems,
which are by far the most common file system type.
Current Practice:
Symbolics Genera implements something very similar to this. [The main
difference is that in Genera, there is no :ABSOLUTE keyword at the head
of the list. This has been shown to cause some problems in dealing with
root directories. Genera represents the root directory by a keyword
symbol (rather than a list) because the list representation was not
adequately general.]
Cost to Implementors:
In principle, nothing about the implementation needs to change except
the treatment of the directory field by MAKE-PATHNAME and
PATHNAME-DIRECTORY. The internal representation can otherwise be left
as-is if necessary.
For implementations that choose to rationalize this representation
throughout their internals and any other implementation-specific
accessors, the cost will be necessarily higher.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Serious portability problems would continue to occur. Programmers would be
driven to the use of implementation-specific facilities because the need
for this is frequently impossible to ignore.
Benefits:
The serious costs of non-adoption would be avoided.
Aesthetics:
This representation of hierarchical pathnames is easy to use and quite
general. Users will probably see this as an improvement in the aesthetics.
Discussion:
This issue was raised a while back but no one was fond of the particular
proposal that was submitted. This is an attempt to revive the issue.
The original proposal, to add a :SUBDIRECTORIES field to a pathname, was
discarded because it imposed an unnatural distinction between a toplevel
directory and its subdirectories. Pitman's guess is the the idea was to
try to make it a compatible change, but since most programmers will
probably want to change from implementation-specific primitives to portable
ones anyway, that's probably not such a big deal. Also, there might have
been some programs which thought the change was compatible and ended up
ignoring important information (the :SUBDIRECTORIES field). Pitman thought
it would be better if people just accepted the cost of an incompatible
change in order to get something really pretty as a result.
This issue used to address the issue of relative pathnames (pathnames
relative to some default which is separately maintained). Pitman removed
this issue for now in order to simplify things. He feels the issue should
be resubmitted under separate cover so that it can be discussed separately.
Variations on this proposal, one or more of which could be factored in if
there were sufficient interest are:
- Flushing the idea of strings as fillers for this field require
implementations to always use a list.
- Relaxing the representation to allow the keyword :ABSOLUTE to
be optional in most cases (but required to represent the root).
- Never using :ABSOLUTE, but requiring that to represent the root
directory, you must use the symbol :ROOT as the filler for the
directory slot.
- Specifying that the representation is either a list of strings
or a list whose car is a keyword such as :RELATIVE or :ROOT.
- Specifying that any implementation-specific contents must be a
list which begins with a keyword other than ones defined by these
proposals. eg, (:OTHER implementation-specific-stuff).
∂05-Jul-88 1454 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88 14:54:00 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00116; Tue, 5 Jul 88 17:51:23 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA19983; Tue, 5 Jul 88 17:55:34 EDT
Message-Id: <8807052155.AA19983@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
Date: Tue, 05 Jul 88 17:55:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Status: For Internal Discussion
The new inquiry functions have been split off into a new issue:
STREAM-CAPABILITIES. The proposal name has been changed back to
DEFINED-CONTRACTS to reflect this.
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
Is always bound to a writable two-way stream that is not a
synonym for any of the the other streams mentioned in this
proposal. It is legal for input from *TERMINAL-IO* be a
permanently empty stream because there may be no convenient
place to read input from (it is also legal for output to
*TERMINAL-IO* to go to a bit-sink; there is no portable way
for a program to detect this case).
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the streams may be synonym-streams for another
one of the streams, whether directly or by indirection
via some composite stream type such as a two-way
stream.
4. Any or all of these streams may be synonym streams for
*TERMINAL-IO*.
5. Any or all of these streams may be synonyms for the a
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex. This problem should now be solved.
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pitman suggests that this issue be renamed to remove "STANDARD-INPUT"
from the name. Pierson hasn't done this for fear of further confusing
people's archives.
Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
∂05-Jul-88 1455 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88 14:54:49 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00214; Tue, 5 Jul 88 17:52:23 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA19990; Tue, 5 Jul 88 17:56:33 EDT
Message-Id: <8807052156.AA19990@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STREAM-CAPABILITIES (version 1)
Date: Tue, 05 Jul 88 17:56:31 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STREAM-CAPABILITIES
References: Standard streams (pp. 327-329)
Category: ADDITION
Edit history: Version 1 by Pierson 7/ 5 88, add redesign per Pitman
Status: For Internal Discussion
Two versions, one from Masinter and one from Pitman.
Problem description:
Portable programs cannot currently determine certain useful
relationships among streams because the required information is
operating-system dependent and unavailable at a portable Common Lisp
level.
---------------------------------------------------------------------------
Proposal (STREAM-CAPABILITIES:NEW-PREDICATES):
Add the following inquiry functions to Common Lisp:
STREAM-SAME-DESTINATION-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams send their
output to the same "destination". For example, this function
would return true for two streams that output to Unix files iff
the streams resulted either in output to the same file
descriptor or in output to two different file descriptors for
the same inode.
STREAM-SAME-SOURCE-P stream1 stream2 [Function]
Returns T if the Lisp can prove that the two streams receive
their input from the same "source", where same source mans that
input on one stream will change what the other stream would next
read. For example, this function would return true for two
streams that read from Unix files iff the streams resulted in
input from the same file descriptor but not if the streams
resulted in in input from two different file descriptors for the
same inode because then reading one stream would not change what
the other stream saw.
INTERACTIVE-STREAM-P stream [Function]
Returns T if the Lisp believes that the stream is interactive.
Some of the things that define a stream as interactive include:
1. The stream is connected to a person, program, or device
such that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program should prompt for input and support "normal
input editing".
3. READ-CHAR might hang waiting for input instead of
immediately returning EOF.
The answer returned by this function may be incorrect; it will
most likely be based on whether or not the stream is connected
to whatever the underlying operating system considers a
"terminal device".
Test Cases/Examples:
(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
(IN2 (OPEN "foo" :DIRECTION :INPUT))
(OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
(OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
(STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
(STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
(LIST (STREAM-SAME-DESTINATION-P STREAM1 OUT1)
(STREAM-SAME-DESTINATION-P STREAM1 STREAM2)
(STREAM-SAME-SOURCE-P STREAM1 IN1)
(STREAM-SAME-SOURCE-P STREAM1 STREAM2)
(STREAM-INTERACTIVE-P STREAM1)
(STREAM-INTERACTIVE-P *TERMINAL-IO*)))
==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive
---------------------------------------------------------------------------
Proposal (STREAM-CAPABILITIES:LIST-FUNCTIONS)
Add the following inquiry functions to Common Lisp:
STREAM-SOURCE-ID-LIST stream [Function]
STREAM-DESTINATION-ID-LIST stream [Function]
Returns a list of tokens which identify the source or the
destination of the stream at the current time. The tokens may
be any Lisp objects distinguishable using EQL. The only valid
operations on the list of tokens are non-destructive set
operations.
A synonym stream always returns the same id list as the stream
to which it is indirected.
An encapsulated stream (such as an echo stream or a broadcast
stream) always returns at least the union of the tokens which
would be returned by each of the encapsulated streams.
INTERACTIVE-STREAM-P stream [Function]
Returns T if the Lisp believes that the stream is interactive.
Some of the things that define a stream as interactive include:
1. The stream is connected to a person, program, or device
such that the program can prompt for information and
expect to receive different input depending on the prompt.
2. The program should prompt for input and support "normal
input editing".
3. READ-CHAR might hang waiting for input instead of
immediately returning EOF.
The answer returned by this function may be incorrect; it will
most likely be based on whether or not the stream is connected
to whatever the underlying operating system considers a
"terminal device".
Test Cases/Examples:
(LET* ((IN1 (OPEN "foo" :DIRECTION :INPUT))
(IN2 (OPEN "foo" :DIRECTION :INPUT))
(OUT1 (OPEN "foo" :DIRECTION :OUTPUT))
(OUT2 (OPEN "foo" :DIRECTION :OUTPUT))
(STREAM1 (MAKE-TWO-WAY-STREAM IN1 OUT1))
(STREAM2 (MAKE-TWO-WAY-STREAM IN2 OUT2)))
(LIST (INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
(STREAM-DESTINATION-ID-LIST OUT1))
(INTERSECTION (STREAM-DESTINATION-ID-LIST STREAM1)
(STREAM-DESTINATION-ID-LIST STREAM2))
(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
(STREAM-SOURCE-ID-LIST IN1))
(INTERSECTION (STREAM-SOURCE-ID-LIST STREAM1)
(STREAM-SOURCE-ID-LIST STREAM2))
(INTERACTIVE-STREAM-P STREAM1)
(INTERACTIVE-STREAM-P *TERMINAL-IO*)))
==> (T T T NIL NIL ?) ; *TERMINAL-IO* might or might not be interactive
---------------------------------------------------------------------------
Rationale:
These inquiry functions answer questions that portable Lisp programs
can't answer on their own because the information is frequently only
maintained at an operating system level.
Current practice:
No implementations currently provide this functionality.
Cost to Implementors:
Implementations will have to support these new functions. Correct
support will require some thought for each operating system supported.
Cost to Users:
None, this is an upward-compatible extension.
Cost of non-Adoption:
Portable programs will have trouble matching their user interface to
different target environments.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations. Portable programs will
have more tools for reasoning about stream relationships.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Masinter doesn't believe that STREAM-SAME-SOURCE-P (or, presumably,
STREAM-SOURCE-ID-LIST) is needed; Pierson disagrees.
INTERACTIVE-STREAM-P is problematical, the information would be useful
to some programs, but it's not clear how many implementations can
return a useful answer.
Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he is
concerned that it may be hard for implementations to provide the list
functions efficiently because the natural token type for multiple,
disjoint types of streams may be integers. The implementation would
have to coerce these integers in to some other type of token that
would be guaranteed unique across all possible stream types.
∂05-Jul-88 1624 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 5 Jul 88 16:24:38 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00752; Tue, 5 Jul 88 19:22:10 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA20327; Tue, 5 Jul 88 19:26:23 EDT
Message-Id: <8807052326.AA20327@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-Reply-To: Your message of Tue, 05 Jul 88 14:56:00 -0400.
<880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Tue, 05 Jul 88 19:26:21 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Actually, I was waiting for Chris Perdue who said in Boston that he
had a draft in review. Thanks for giving us all a kick.
dan
∂06-Jul-88 0720 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 6 Jul 88 07:20:19 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01125; Wed, 6 Jul 88 10:17:35 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429040; Wed 6-Jul-88 10:19:18 EDT
Date: Wed, 6 Jul 88 10:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 6)
To: pierson%mist@MULTIMAX.ARPA
Cc: cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
In-Reply-To: <8807052155.AA19983@mist.UUCP>
Message-Id: <880706101913.3.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Tue, 05 Jul 88 17:55:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
...
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
...
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the streams may be synonym-streams for another
one of the streams, whether directly or by indirection
via some composite stream type such as a two-way
stream.
I would say something more like:
"None of the standard streams (including *TERMINAL-IO*) may be directed
by synonym stream to another of these stream variables (except *TERMINAL-IO*),
whether directly or by indirection via some composite stream such as a
two-way stream with one of the arms being a synonym stream."
The reason being that you need to restrict *TERMINAL-IO*, and also that
you don't want to restrict people pointing at the contents of one of
these variables, you just don't want them actually being synonyms for the
variable itself.
4. Any or all of these streams may be synonym streams for
*TERMINAL-IO*.
5. Any or all of these streams may be synonyms for the a
I believe the "the" here is spurious.
common implementation dependent stream. For example,
...
Test Cases/Examples:
...
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *DEBUG-IO* was
I'd say "if" not "because" here.
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
Maybe also note that this could happen only if *DEBUG-IO* was not its original
setting, since the original setting of *DEBUG-IO* is currently a synonym stream
to *TERMINAL-IO*. So the example is in some sense more complicated than you
show. Maybe you could just change the example to be something that shows the
behavior. Eg,
(DEFUN FOO ()
(LET ((*DEBUG-IO* (MAKE-TWO-WAY-STREAM (MAKE-SYNONYM-STREAM '*STANDARD-INPUT*)
(MAKE-SYNONYM-STREAM '*STANDARD-OUTPUT*))))
(BAR)))
(DEFUN BAR ()
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
(PRINT 'FOO)))
With this proposal:
Would be guaranteed not to cause a circular stream reference.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
Well, not guaranteed not to cause a circular reference. Rather, users would be
warned that the code that led to a circular reference was an error.
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Right. Maybe mention that this could conceivably happen in the initial
configuration of some implementations.
...
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output.
Symbolics Genera binds *TERMINAL-IO* as appropriate for each process,
usually to a `window' for interactive applications or to a stream which
will conjure an interaction window on demand for background tasks.
...
Discussion:
Pitman was concerned that the initial version of this proposal didn't
provide a guaranteed way to get back the initial streams after
rebinding, e.g. *standard-io*. The second version of this proposal
offered a solution to that problem which was generally considered too
complex. This problem should now be solved.
I'm not sure that this continues to be relevant enough to take up space
in the proposal. People can read the old proposal versions if they care.
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists.
It might be well to plainly identify that this issue is not really
addressed by the above proposal.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pitman suggests that this issue be renamed to remove "STANDARD-INPUT"
from the name. Pierson hasn't done this for fear of further confusing
people's archives.
...
This doesn't need to be here either. If no one cares, I'll live with the
funny name. Brevity is most important, I think.
∂06-Jul-88 1836 CL-Cleanup-mailer EQUAL-STRUCTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Jul 88 18:36:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 06 JUL 88 18:36:11 PDT
Date: 6 Jul 88 18:35 PDT
From: Masinter.pa@Xerox.COM
Subject: EQUAL-STRUCTURE
to: cl-cleanup@sail.stanford.edu
Message-ID: <880706-183611-1212@Xerox>
After all the debate, I'm convinced that the worst thing that we can do is to
change it without fixing it, and that it is unfixable. I think taking it out is
too radical, and so we should just clarify that it doesn't descend into any
structure that CLtL doesn't mention that it explicitly descends into.
∂07-Jul-88 0824 CL-Cleanup-mailer Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88 08:24:47 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429853; Thu 7-Jul-88 11:24:18 EDT
Date: Thu, 7 Jul 88 11:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707112359.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PATHNAME-SYNTAX-ERROR-TIME
References: File System Interface (pp409-427)
Category: CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There exist conceivable pathnames for which there is no valid mapping in a
particular implementation. CLtL is not clear about the time at which this
error might be detected.
For example, on file systems which constrain pathname-types to be three
letters or fewer, the type "LISP" is not valid. The question arises: when
is this error detected?
In some implementations, the error might be detected while forming the
pathname. That is, (MAKE-PATHNAME :TYPE "LISP") signals an error.
In some implementations, the error might be detected while forming the
namestring. That is, (MAKE-PATHNAME :TYPE "LISP") succeeds, but
(NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) signals an error.
In some implementations, validity checking might be done only by the host
operating system, so Lisp does not detect the error unless the operating
system complains. For example, (MAKE-PATHNAME :TYPE "LISP") succeeds,
and even (NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) constructs a plausible
looking pathname, but (OPEN (NAMESTRING (MAKE-PATHNAME :TYPE "LISP"))) fails.
In some implementations, Lisp might make `friendly' corrections to the
pathname in order to form a namestring. For example,
(MAKE-PATHNAME :TYPE "LISP") might succeed, but
(NAMESTRING (MAKE-PATHNAME :TYPE "LISP")) might produce a namestring with
an extension such as ".LIS" or ".LSP".
Similar issues might come up in file systems which don't allow wildcard
pathnames. Is :WILD allowed in a name or type slot and then disallowed
upon coercion to a pathname, or is :WILD complained about "up front"?
This phenomenon is a barrier to portability because if a program is
debugged in an implementation that does, for example, NAMESTRING-time
error checking, the programmer may be lulled into an expectation that
it is acceptable to construct and manipulate invalid pathnames as long
as the problem is caught before an attempt to call NAMESTRING is
attempted. On the other hand, another programmer may debug his code in
a Lisp which does early error checking of syntax and may assume that
he is home free if the pathname gets constructed correctly.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION):
Clarify that operations such as MAKE-PATHNAME and MERGE-PATHNMES which
construct new pathnames do plausibility checking of their arguments
and signal an error rather than construct a pathname for which NAMESTRING
would not produce a valid pathname.
Rationale:
This would identify clearly to the programmer where he should expect an
error to be signalled for a pathname.
This would mean that fully constructed pathnames could reliably
be converted to namestrings.
Cost to Implementors:
Some implementors, especially those which rely on the operating system
to be the sole authority on pathname syntax, might have to introduce
some new syntax-checking facilities.
Implementations where this error checking is done later would have to be
changed both to do it earlier, and to not make the unwarranted assumption
that pathnames with no valid namestring representation are constructable.
Cost to Users:
The ability to represent non-viable pathnames for the purpose of merging
would be lost. This feature was not portably available, but was available
in some operating systems.
Some code which expected an error, but expected it at a different time
would have to be changed.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION):
Clarify that it was valid to create a pathname which could not be
converted to a namestring. Require NAMESTRING (and related functions,
such as ENOUGH-NAMESTRING or any internal functions that might be used
in place of NAMESTRING by functions like OPEN and PROBE-FILE) to signal
an error for pathnames which do not represent valid filenames in the
designated file system.
Rationale:
This would identify clearly to the programmer where he should expect an
error to be signalled for a pathname.
This would allow the construction of pathnames for the sole purpose of
merging without causing what might seem to some as gratuitous errors.
Cost to Implementors:
Implementors who rely on the operating system to be the sole authority
on pathname syntax, might have to introduce some new syntax-checking
facilities.
Implementations where this error checking is done earlier would have to
be changed both to do it later, and to not make the unwarranted
assumption that any pathname has a valid namestring representation.
Cost to Users:
Early error checking of faulty pathnames would be lost.
Some code which expected an error, but expected it at a different time
would have to be changed.
Benefits:
Macsyma, for example, has encountered a need for "hostless" pathnames
(in merging). The concept makes no sense if every pathname must have
a namestring, because a pathname with no host cannot have a namestring.
However, if it's NAMESTRING's responsibility to signal an error, then
hostless pathnames are still useful for merging. Consider:
(MERGE-PATHNAMES (MAKE-PATHNAME :NAME "FRED") MARY)
This will override both the NAME and the HOST field of MARY because you
must currently have a host in every pathname. But if MAKE-PATHNAME did
not force the host, or if one could explicitly say :HOST NIL, then
such pathnames would be considerably more useful for merging.
Proposal (PATHNAME-SYNTAX-ERROR-TIME:EXPLICITLY-VAGUE):
Clarify that we were unable to reach agreement on this issue and that
the time at which this error detection occurs is not well-specified.
Advise the editorial group to warn users clearly about this known source
of program portability problems.
Rationale:
This implements the status quo.
Cost to Implementors:
None.
Cost to Users:
No existing code must be modified, but there is an ongoing cost
associated with providing error checking at multiple points in a
program because implementations disagree as to where an error
might be signalled. In some cases, the effects of having to handle
this in multiple places may cause unpleasant modularity violations.
Test Case:
See problem description.
Current Practice:
Symbolics Genera signals an error at pathname construction time if a
pathname will be invalid. Once a pathname is successfully constructed,
it can generally be assumed that NAMESTRING will always succeed.
Aesthetics:
Making this more well-defined would cause a definite aesthetic
improvement to some programs.
Discussion:
Pitman prefers PATHNAME-SYNTAX-ERROR-TIME:NAMESTRING-COERCION but
believes that anything is an improvement over ...:EXPLICITLY-VAGUE.
CL pathname functions were not adequate for use in Macsyma because
they did not adequately represent to-be-merged-only pathnames (a
feature used very extensively in Macsyma), because errors could be
signalled at radically different times. To get around this, Pitman
had to create a data structure in Macsyma called an MPATHNAME which
was only trivially different than a PATHNAME but which made it
possible to deal portably with this issue of when errors occurred
and what kinds of errors occured. Unfortunately, since none of the
CL functions worked on MPATHNAMEs, a whole series of functions,
also only trivially different, had to be created: MAKE-MPATHNAME,
MNAMESTRING, MERGE-MPATHNAMES, MPATHNAME-NAME, MPATHNAME-TYPE,
MOPEN, WITH-MOPEN-FILE, etc.
∂07-Jul-88 0908 CL-Cleanup-mailer RE: Issue: SYMBOL-MACROLET-UTILITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Jul 88 09:08:04 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA02117; Thu, 7 Jul 88 09:07:29 PDT
Date: Thu, 7 Jul 88 09:07:29 PDT
Message-Id: <8807071607.AA02117@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Gregor.pa@xerox.com
Subject: RE: Issue: SYMBOL-MACROLET-UTILITY
> This isn't a problem description, it is a statement of opinion. A
> problem description would say something like:
>
> The symbol-macrolet utitily introduced with CLOS has some semantic
> problems. <discussion of these problems here>. These problems may
> cause problems with some existing code <extension of previous
> discussion here>.
I'm not completely happy with the problem description as it stands, either. I
see the issue as essentially a choice between (a) fixing the semantics of
SYMBOL-MACROLET to match the semantics of MACROLET, or (b) doing without
SYMBOL-MACROLET. I had thought I could separate these into two issues
(namely, keep-vs.-flush first, and fix the semantics only if flush fails), but
now I think I should combine them into one issue after all. This will be
forthcoming.
> Cost to Users:
>
> Users will lose the expressive ability provided by SYMBOL-MACROLET,
> WITH-ACCESSORS, and WITH-SLOTS, and will have to make do with
> MACROLET.
>
>Another cost is that they won't be able to overload names to mean both
>a real function and one of these hack macros. For example:
>
>(defclass foo () (car cdr))
>
>(defun describe-foo (foo)
> (macrolet ((car () (slot-value foo 'car))
> (cdr () (slot-value foo 'cdr)))
> ...
> Can't use normal car and cdr in here
> ...))
>
>Of course this is something that Scheme programmers are used to dealing
>with. But Common Lisp programmers are not. The potential for this
>seriously aggravating the existing problem with macro expansions
>capturing the wrong lexical context is huge.
The namespace argument is a valid one; I'll put that in "Cost to Users". This
is honestly the first pro-SYMBOL-MACROLET argument I've heard that has more
substance than "But it'd be neat to have SYMBOL-MACROLET."
Characterizing the namespace collision problem as "huge," based on the example
you give, assumes that (a) people have some proclivity toward using names that
conflict with function names like "car" and "cdr", (b) they'd use the same
name for both the macro and the slot (cf. defstruct and the :conc-name prefix
mechanism), and (c) someone writing
(macrolet ((car () ...)) ...)
wouldn't see the name collision. I might believe the first assumption
(especially for names like "list"), I'm more dubious of the second, and I
really have a hard time swallowing the third assumption. Even in a Lisp-2,
programmers are used to avoiding name conflicts.
I tend to believe that changing WITH-SLOTS and WITH-ACCESSORS could eliminate
CLOS' need for SYMBOL-MACROLET altogether, if they just generated MACROLET
macros with prefixes.
> Cost of Non-Adoption:
>
> Implementors must implement significant new functionality, adding to
> system size and language complexity. (A separate proposal,
> SYMBOL-MACROLET-SEMANTICS, addresses problems with the currently
> specified semantics of SYMBOL-MACROLET.)
>
> I am not sure I buy this. For one, there is already an implementation
> of it in PCL. For another, any exiting compiler must already have the
> right stuff in it to do this.
>
> If you insist on doing an entirely custom CLOS, the work required to do
> this part of it is very small compared to the work required to do the
> rest of it.
I guess I was getting ahead of myself here. I'd been taking it as an almost
foregone conclusion that, if SYMBOL-MACROLET is kept in the language, it would
be promoted to a special form, in which case the PCL implementation doesn't
really help anybody. Another reason to combine this with the
fix-the-semantics issue.
/JEP
∂07-Jul-88 1136 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88 11:36:33 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 429994; Thu 7-Jul-88 14:36:18 EDT
Date: Thu, 7 Jul 88 14:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PATHNAME-CANONICAL-TYPE
References: MAKE-PATHNAME (p416)
Category: ADDITION
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Related-Issues: PATHNAME-COMPONENT-CASE
Problem Description:
The pathame-type of ``Lisp'' and ``Compiled Lisp'' files vary widely from
implementation to implementation.
"LSP" is common on Vax VMS. "lisp" is generally used for the Symbolics
file system. "l" and "lisp" are common on Unix. Some Lisp implementations
use customized extensions such as "cl" or even "jcl" (eg, for "Joe's CL").
It would be useful to probe the existence of either a source or a binary
file, but that cannot currently be done portably. Furthermore, it would be
useful to create certain standard kinds of files in a system-independent
fashion.
A common desire, for example, is to do
(DEFUN FILE-NEEDS-TO-BE-COMPILED (FILE)
(LET ((SOURCE (PROBE-FILE
(MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???))))
(BINARY (PROBE-FILE
(MERGE-PATHNAMES FILE (MAKE-PATHNAME :TYPE ???)))))
... (FILE-WRITE-DATE SOURCE) ... (FILE-WRITE-DATE BINARY) ...))
The problem is that there's nothing portable to put in the ??? positions.
Indeed, depending on the host (ie, file system) of the pathname, the
type might need to differ even in the same Lisp implementation. For example,
Symbolics Genera stores its source files in names like "foo.l" on Unix,
"FOO.LSP" on VMS, etc.
Proposal (PATHNAME-CANONICAL-TYPE:NEW-CONCEPT):
In addition to the normal strings and keywords currently allowed as fillers
of the TYPE field of a pathname, allow other keywords which designate
``canonical types''.
A canonical type is translated to a real type by MAKE-PATHNAME so that the
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE canonical-type)) is a string.
Introduce a new function PATHNAME-CANONICAL-TYPE which returns the canonical
type of an argument pathname, or the type if there is no canonical type.
For example,
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
[This information may be explicitly represented as an additional slot, or
computed on demand using a lookup table, as the implementor prefers.]
Define the following standard types:
:LISP ``Lisp'' (source) file
:BIN ``Compiled Lisp'' (object) file
Permit implementations to extend the set of canonical type names.
Test Case:
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :LISP))
=> "LSP" ;Typically, on VMS
=> "l" or "lisp" ;Typically, on Unix
=> "L" or "LISP" ;Typically, on Unix
; (assuming PATHNAME-COMPONENT-CASE:CANONICALIZE adopted)
..etc.
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :BIN))
=> "FAS" ;eg, VAXLISP
=> "BIN" ;eg, Symbolics file system
...etc.
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE "LSP"))
=> :LISP ;eg, VAXLISP
=> "LSP" ;eg, Unix
Rationale:
This is a useful subset of the functionality already available in
at least one implementation.
Current Practice:
Symbolics Genera implements this proposal.
Cost to Implementors:
The cost of implementing these proposed features is very slightly.
MAKE-PATHNAME would have to change to coerce its :TYPE argument in implementations
where it does not do so already. PATHNAME-CANONICAL-TYPE can be implemented as a
fairly straightforward lookup.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
It would continue to be hard to portably name files when their types
differed from file system to file system.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Some programs would be able to abstract away from the particulars of the host
file system entirely. Some people believe this would be a definite improvement
in aesthetics.
Discussion:
Note that different Lisp implementations which share the same file system,
need not and perhaps should not agree on the same type string for the
canonical type :BIN. That is, if I store source files on VAX VMS and compile
them both for use under Symbolics Genera and VAXLISP, then it is both
appropriate and useful that VAXLISP :BIN files be named "something.FAS"
and Genera :BIN files be named "something.BIN" since then they wouldn't
clobber each other.
Pitman supports PATHNAME-CANONICAL-TYPE:NEW-CONCEPT.
∂07-Jul-88 1308 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88 13:08:04 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430072; Thu 7-Jul-88 16:07:49 EDT
Date: Thu, 7 Jul 88 16:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707160733.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: PACKAGE-CLUTTER
References: LISP package (p181)
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL prohibits this, but it leads to problems in general.
For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that the LISP package must contain not only all the symbols
mentioned as part of the LISP package in standard, but only those symbols.
Specify that symbols in the LISP package may not have definitions other
than those specified.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it may
not be bound, defined as a type, or defined as a function, macro or
special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Symbolics Genera currently has exactly the set of symbols on it which is
prescribed by CLtL. A few symbols, such as EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables. The symbol LAMBDA is defined
as a macro. There may be a few other exceptions like this.
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This issue came up a while back on Common-Lisp list. It got bogged down in
discussions of what the USER package and other system-specific packages might
contain. This proposal avoids the sticky issue of whether the USER package may
contain symbols other than those specified in the standard. The smart programmer
of portable code will never rely on the contents of the USER package anyway.
Pitman supports PACKAGE-CLUTTER:REDUCE.
∂07-Jul-88 1312 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jul 88 13:12:42 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430076; Thu 7-Jul-88 16:12:27 EDT
Date: Thu, 7 Jul 88 16:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: IN-PACKAGE-FUNCTIONALITY
References: IN-PACKAGE (p183)
Category: CHANGE
Edit history: 07-Jul-88, Version 1 by Pitman
Related-Issues: DEFPACKAGE
Status: For Internal Discussion
Problem Description:
There are two typical uses for IN-PACKAGE -- to define/create a package
and to select a package. The fact that these two purposes have been
given to the same function has led to reduced error checking.
Proposal (IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY):
Eliminate the ability of IN-PACKAGE to create a package on demand.
Require IN-PACKAGE to signal an error if the package does not exist.
Eliminate the :NICKNAMES and :USE arguments to IN-PACKAGE, since they
are no longer needed.
Clarify that DEFPACKAGE is the preferred way to declare a package,
and MAKE-PACKAGE is the preferred way to construct a package at runtime.
Eliminate the compile-time processing requirement for all package-related
functions except IN-PACKAGE and DEFPACKAGE.
Test Case:
#1: (IN-PACKAGE 'NO-SUCH-PACKAGE) ;signals an error
#2: (DEFPACKAGE FOO ...options...) ;defines/creates a package
(IN-PACKAGE 'FOO) ;selects an existing package
Rationale:
This would greatly improve error checking and modularity, with only minimal
loss of functionality. Any call to IN-PACKAGE which really needed to
demand-create a package could be rewritten as a DEFPACKAGE followed by an
IN-PACKAGE.
Current Practice:
Probably no one implements this behavior since it's in direct
contradiction of both the definitions and numerous examples in CLtL.
Cost to Implementors:
This change would be straightforward to implement.
The cost may not be trivial in all cases, but should not be very large.
Cost to Users:
In most cases, minor syntactic changes to some files would be necessary.
In many cases, no changes would be necessary since files may already be
doing IN-PACKAGE in situations where the author is hoping he's made sure
the real package declaration is already loaded.
Cost of Non-Adoption:
Reduced error checking.
Less modular code.
Benefits:
Errors due to demand-creation of a package by IN-PACKAGE without appropriate
uses of the :USE or :NICKNAMES or without appropriate calls to EXPORT, etc.
afterward would be easier to detect.
Modular package declarations would be encouraged.
Aesthetics:
The fact that IN-PACKAGE is currently ambiguous about intent (whether the
package should exist already or not) is clearly not aesthetic. This change
would be an aesthetic improvement.
Discussion:
Pitman supports IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY.
As written, this proposal is necessarily contingent on DEFPACKAGE:ADDITION.
Note, however, that the attempt by this proposal to reduce the set
of arguments allowed to IN-PACKAGE is not inconsistent with the attempt by
DEFPACKAGE:ADDITION to increase the set of arguments. That proposal,
which is a compatible addition, presupposes that IN-PACKAGE is still
usable both for selection and creation, so it correctly attempts to
generalize the arguments it requires. This proposal, which is an
incompatible change, uses DEFPACKAGE as a foothold to change the model
of how IN-PACKAGE is used -- only once that new model is in place does
it make sense to consider eliminating arguments to IN-PACKAGE.
∂08-Jul-88 0310 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 8 Jul 88 03:09:57 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04525; 8 Jul 88 10:07 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa24723;
8 Jul 88 10:26 BST
To: KMP@scrc-stony-brook.arpa
CC: CL-Cleanup@sail.stanford.edu
In-reply-to: Kent M Pitman's message of Thu, 7 Jul 88 16:12 EDT <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Date: Fri, 8 Jul 88 10:26:07 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
I support strongly the IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY proposal.
I have been confused by the dual use of IN-PACKAGE which is not
helpful.
==John
∂08-Jul-88 0541 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:41:28 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430361; Fri 8-Jul-88 08:41:10 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430318; 8 Jul 88 03:37:40 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA17975@EDDIE.MIT.EDU>; Fri, 8 Jul 88 03:37:19 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 02:56:28 EDT (Fri)
Date: 8 Jul 88 02:56:28 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Message-Id: <8807080256.AA14902@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:41 EDT
Resent-Message-ID: <880708084100.2.KMP@PEWEE.SCRC.Symbolics.COM>
In many environments where lisps operate, "binary" refers to something other
than compiled lisp files (e.g., the executable files of the host system).
Therefore I think the use of :BIN for compiled lisp code is a bad choice, as
it precludes the use of :BIN for implementation-dependent local extensions
where :BIN might be the most natural name (I can imagine some such
implementations ending up with both :BIN and :BINARY, and you have to remember
which is which). I would prefer :COMPILED-LISP. Of course implementations
would be free to accept :BIN as a synonym for :COMPILED-LISP (especially in
the cases where compiled lisp files ARE in fact the executable files of the
host system :-).
If you'd prefer something terse, I'd suggest :COMPILED or :LOAD.
∂08-Jul-88 0542 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:42:08 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430362; 8 Jul 88 08:41:44 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430319; 8 Jul 88 03:38:09 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA17985@EDDIE.MIT.EDU>; Fri, 8 Jul 88 03:37:44 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 03:02:56 EDT (Fri)
Date: 8 Jul 88 03:02:56 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880707160733.8.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 1)
Message-Id: <8807080302.AA14914@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:41 EDT
Resent-Message-ID: <880708084135.3.KMP@PEWEE.SCRC.Symbolics.COM>
How about the use of LISP package symbols for property names?
∂08-Jul-88 0545 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:30 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430369; Fri 8-Jul-88 08:45:15 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430096; 7 Jul 88 16:36:50 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA05217@EDDIE.MIT.EDU>; Thu, 7 Jul 88 16:36:37 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:09:32 EDT (Thu)
Date: 7 Jul 88 16:09:32 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807071609.AA13398@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084513.4.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
I think this is pointless. Why should there be special syntax for "*" but
not for "x*z"? It only gives you the ability to detect a small subset of
possible wildcard specs, and it only gives you the ability to construct
a small subset of wildcard specs (and there's nothing equivalent for even
this small subset within file names or types or devices). It's a hack, which
might get in the way of a more general solution. Why not just leave everything
as strings for now, and leave other data types for any possible less ad hoc
approaches to the wildcard issues.
∂08-Jul-88 0545 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430370; Fri 8-Jul-88 08:45:25 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430095; 7 Jul 88 16:36:39 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA05212@EDDIE.MIT.EDU>; Thu, 7 Jul 88 16:36:27 EDT
Received: by spt.entity.com (smail2.5); 7 Jul 88 16:27:55 EDT (Thu)
Date: 7 Jul 88 16:27:55 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <880705145610.9.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807071627.AA13436@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084529.5.KMP@PEWEE.SCRC.Symbolics.COM>
The Macintosh has syntax for moving up the directory structure. This is
similar to Unix's "../", although unlike Unix where there's an explicit ".."
pseudo-component, on the Macintosh it's just syntax. In any case, I'd like to
see your proposal extended to allow representing upward motion. Otherwise it
needs to be made clear that counting the number of elements in the
subdirectory list doesn't necessarily say anything about the nesting level of
the directory (it's neither a lower nor an upper bound).
∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:58 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430372; Fri 8-Jul-88 08:45:43 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430112; Thu 7-Jul-88 16:49:55 EDT
Date: Thu, 7 Jul 88 16:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8807071609.AA13398@spt.entity.com>
Message-ID: <880707164958.0.KMP@PEWEE.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084547.7.KMP@PEWEE.SCRC.Symbolics.COM>
Date: 7 Jul 88 16:09:32 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
Date: Tue, 5 Jul 88 14:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
(PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
=> (:ABSOLUTE "FOO" :WILD "BAR")
I think this is pointless. Why should there be special syntax for "*" but
not for "x*z"? It only gives you the ability to detect a small subset of
possible wildcard specs, and it only gives you the ability to construct
a small subset of wildcard specs (and there's nothing equivalent for even
this small subset within file names or types or devices). It's a hack, which
might get in the way of a more general solution. Why not just leave everything
as strings for now, and leave other data types for any possible less ad hoc
approaches to the wildcard issues.
I'm not sure of this myself, but I've not studied the issue well enough.
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.
I think the main intent is to allow a person to write a portable call
like (DIRECTORY (MAKE-PATHNAME :NAME "FOO" :TYPE :WILD :VERSION :WILD))
without worrying that "*" might not be the wildcard char in all systems.
It just occurred to me that you are (and I was) supposing that "*" is
what :WILD translates to, but in fact it might not be. I guess I think
it's defensible (albeit less elegant) to support this particular special
case because it does have broader application in portable programs.
Btw, even systems which support embedded "*" disagree as to its
treatment. In some (eg, ITS) the * matches exactly one char, while in
others (eg, Unix or Lispm), it matches any number of chars.
Interestingly, ITS agrees however that when "*" stands alone that it
matches a variable number of chars...
∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:45:56 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430371; Fri 8-Jul-88 08:45:35 EDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430107; Thu 7-Jul-88 16:43:50 EDT
Date: Thu, 7 Jul 88 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: gz@spt.entity.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8807071627.AA13436@spt.entity.com>
Message-ID: <880707164340.9.KMP@PEWEE.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084539.6.KMP@PEWEE.SCRC.Symbolics.COM>
Date: 7 Jul 88 16:27:55 EDT (Thu)
From: gz@spt.entity.com (Gail Zacharias)
The Macintosh has syntax for moving up the directory structure. This is
similar to Unix's "../", although unlike Unix where there's an explicit ".."
pseudo-component, on the Macintosh it's just syntax. In any case, I'd like to
see your proposal extended to allow representing upward motion. Otherwise it
needs to be made clear that counting the number of elements in the
subdirectory list doesn't necessarily say anything about the nesting level of
the directory (it's neither a lower nor an upper bound).
If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then
if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
the absolute nesting level. If (MEMBER :WILD-INFERIORS something), then
I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
lower bound on the nesting level.
The idea would be for all such funny syntaxes to be relegated to :RELATIVE.
The lispm represents relative pathnames like lispm's "<<foo>bar.lisp"
as (MAKE-PATHNAME :DIRECTORY (:RELATIVE :UP :UP "FOO") :NAME "BAR" :TYPE "LISP").
I'll have to study how it does merging before sending out a proposal, but
do you see any obvious problems with this notation?
∂08-Jul-88 0546 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 05:46:11 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430373; Fri 8-Jul-88 08:45:51 EDT
Return-path: <spt!gz@EDDIE.MIT.EDU>
Received: from EDDIE.MIT.EDU by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 430344; 8 Jul 88 06:13:33 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA20751@EDDIE.MIT.EDU>; Fri, 8 Jul 88 06:13:15 EDT
Received: by spt.entity.com (smail2.5); 8 Jul 88 05:55:05 EDT (Fri)
Date: 8 Jul 88 05:55:05 EDT (Fri)
From: gz@spt.entity.com (Gail Zacharias)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
In-Reply-To: <880707164958.0.KMP@PEWEE.SCRC.Symbolics.COM>,
<880707164340.9.KMP@PEWEE.SCRC.Symbolics.COM>
Message-Id: <8807080555.AA15328@spt.entity.com>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Fri, 8 Jul 88 08:45 EDT
Resent-Message-ID: <880708084555.8.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 7 Jul 88 16:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.
Oops, you're right, I forgot all about this. "Never mind".
Date: Thu, 7 Jul 88 16:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
If (CAR (PATHNAME-DIRECTORY ...)) yields (:ABSOLUTE . something), then
if (NOT (MEMBER :WILD-INFERIORS something)) then (LENGTH something) is
the absolute nesting level.
I don't think (member :wild-inferiors ...) is sufficient. What about
implementations that allow more than one way to specify multi-level inferiors
(e.g. something along the lines of "x**y"). Such implementations can pick one
pattern to be represented by :WILD-INFERIORS, but they can't replace *every*
multi-level pattern with :WILD-INFERIORS without losing information. So
there's no implementation-independent way of getting an upper bound (or more
generally of knowing for certain whether a given component is wild or not).
It might be better for the subdirectory list to be just a list of <whatever>'s,
and provide predicates for testing components for wildness and/or
multi-levelness. (:WILD and :WILD-INFERIORS could still be required to be
recognized on input). I think :UP might just be a keyword, since I can't
imagine there being more than one way of moving up. But maybe this should
be a predicate as well just in case.
Another possibility might be for a component to be either a string
or a list (string . properties), where properties would be things like
:WILD, :RESTRICTED-WILD, :MULTI-LEVEL, :UP. A plain string means it's
a simple (non-wild) component.
If (MEMBER :WILD-INFERIORS something), then
I think (- (LENGTH something) (COUNT :WILD-INFERIORS something)) is a
lower bound on the nesting level.
The idea would be for all such funny syntaxes to be relegated to :RELATIVE.
I think then that you're overloading :ABSOLUTE to mean both rooted and
canonicalized. A unix name like "/foo/bar/../baz/" is fully rooted even
though it contains some relative motion within it. It's functionally (in the
file system) fully equivalent to "/foo/baz/", but it might not be equivalent
programmatically (i.e. it might intentionally appear in the middle of some
pathname-manipulating algorithm). Just on general principle, if a user says
"/foo/bar/../baz/", I would not feel comfortable with the loss of information
inherent in *automatically* reducing that to "/foo/baz/" at the pathname
level. I think of this as a TRUENAME-level action.
In fact, a TRUENAME-like function, say STANDARDIZE-PATHNAME, which didn't
actually require the file (or the directory) to exist, but just did as much
canonicalization as possible, might solve some of these problems. We (Coral)
have an internal function like that, it expands lisp-defined logical names and
removes syntactically redundant subdirectory motion (as well as any unnecessary
quoting). It's useful. Handling subdirectory structures is much simpler if
you can get the system to standardize them for you first.
One more observation, about the :ABSOLUTE/:RELATIVE distinction. The Macintosh
has a hierarchical file system, and relative pathnames, but it doesn't have a
root directory. Pathnames are rooted at the device, sort of like twenex
(except twenex doesn't really deal with relative pathnames. Maybe VMS is a
better analogy). Anyhow what this means is that being absolute or relative is
not a property of the directory alone, it's a property of the device/directory
pair. This isn't really a big deal, as I'm sure we can come up with some set
of conventions, but it does seem like it would introduce unnecessary conceptual
hair for our non-jet-setting users (i.e. Mac folks who don't really know from
other file systems). I think I would prefer the following option from your
discussion section, as being less intrusive for hierarchical file systems
without a root directory:
- Never using :ABSOLUTE, but requiring that to represent the root
directory, you must use the symbol :ROOT as the filler for the
directory slot.
I interpret this to mean that on unix, "foo/bar/" would be ("foo" "bar")
while "/foo/bar/" would be (:ROOT "foo" "bar"). With that interpretation,
I would also:
. state that this is the convention for output from pathname accessors, and
that using it on input to constructors may be non-portable (it would
signal an error in file systems without a root directory)
. state that the presence of :ROOT (probably?) means the pathname is absolute,
but the converse is not necessarily true (in particular it's false in file
systems without a root directory).
. add a predicate which takes a pathname and tells you if the pathname
as a whole is absolute (i.e. independent of any "current directory").
∂08-Jul-88 1028 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 8 Jul 88 10:28:30 PDT
Received: by labrea.stanford.edu; Fri, 8 Jul 88 10:28:04 PDT
Received: from bhopal.lucid.com by edsel id AA06008g; Fri, 8 Jul 88 10:21:41 PDT
Received: by bhopal id AA15658g; Fri, 8 Jul 88 10:21:40 PDT
Date: Fri, 8 Jul 88 10:21:40 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
Message-Id: <8807081721.AA15658@bhopal.lucid.com>
To: gz@spt.entity.com
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Gail Zacharias's message of 8 Jul 88 05:55:05 EDT (Fri) <8807080555.AA15328@spt.entity.com>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
> I think :UP might just be a keyword, since I can't
> imagine there being more than one way of moving up.
Assume you are using some version of un*x, and that /foo/b1/b2 is a
symbolic link to directory /foo/a1/a2/a3.
Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.
I.e., if you are trying to emulate the behavior of csh, you must wait
until the truename is resolved before knowing where :UP will lead you.
In Lucid Common Lisp for the Sun-3, I get the following behavior,
assuming /u/jlm/b1/b2 is a symbolic link to ../a1/a2/a3, and all the
relevant directories actually exist:
> (cd "/u/jlm/")
#P"/u/jlm/"
> (setq aa (pathname "b1/b2/.."))
#P"b1/b2/.."
> (cd aa)
#P"/u/jlm/a1/a2/"
>
The moral is that (not (eq :UP :UNDO)).
jlm
∂08-Jul-88 1420 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 8 Jul 88 14:16:21 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00143; Fri, 8 Jul 88 17:13:45 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA24313; Fri, 8 Jul 88 16:58:13 EDT
Message-Id: <8807082058.AA24313@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
Date: Fri, 08 Jul 88 16:58:07 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Version 7 by Pierson 7/ 8/88, clean up per Pitman
Status: For Internal Discussion
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to open streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the standard streams (including *TERMINAL-IO*)
may be directed by synonym streams to another of these
stream variables (except *TERMINAL-IO*), whether
directly or by indirection via some composite stream
such as a two way stream with one of the arms being a
synonym stream.
4. Any or all of these streams may be synonyms for the a
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference if *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output. Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. This proposal fails to address this.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pierson supports STANDARD-OUTPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
∂08-Jul-88 1457 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Jul 88 14:57:10 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 430755; Fri 8-Jul-88 17:56:11 EDT
Date: Fri, 8 Jul 88 17:56 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 7)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8807082058.AA24313@mist.UUCP>
Message-ID: <880708175600.2.KMP@PEWEE.SCRC.Symbolics.COM>
Minor residual nit picking...
* In the Proposal section, numbered item 4, end of line 1, the
typo "the a" still appears.
* In the second example, you are guaranteed that this works only
if you haven't changed the value of *DEBUG-IO*. Note that, unlike
the third example which uses the variable *TERMINAL-IO* which
users are forbidden to change, *DEBUG-IO* has no such restriction.
Since your proposal says clearly that these are constraints only
on the initial values, the claim on the second example is a bit
strong. [I would be ammenable to expanding the proposal to say that
it `is an error' (ie, has undefined effects) if you do any later
bindings or assignments which invalidates one of the assertions you
have listed.
In spite of the above, it's ok to go ahead and start listing me as a
supporter of this proposal.
∂08-Jul-88 1522 CL-Cleanup-mailer Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 8 Jul 88 15:22:13 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00490; Fri, 8 Jul 88 18:19:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA24471; Fri, 8 Jul 88 18:23:54 EDT
Message-Id: <8807082223.AA24471@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Date: Fri, 08 Jul 88 18:23:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I've finally changed the status to "Ready for Release?". Does anyone
disagree?
Issue: STANDARD-INPUT-INITIAL-BINDING
References: Standard streams (pp. 327-329)
Category: CHANGE
Edit history: Version 1 by Pierson and Haflich 1/19/87
Version 2 by Pierson 2/29/88
Version 3 by Pierson 5/23/88, per comments by Moon
Version 4 by Pierson 5/26/88, clean up
Version 5 by Pierson 6/28/88, simple design per Masinter
Version 6 by Pierson 7/ 5/88, clean up and split issue
Version 7 by Pierson 7/ 8/88, clean up per Pitman
Version 8 by Pierson 7/ 8/88, yet more clean up
Status: Ready for Release?
Problem description:
CLtL requires that *STANDARD-INPUT*, *STANDARD-OUTPUT*,
*ERROR-OUTPUT*, *TRACE-OUTPUT*, *QUERY-IO*, and *DEBUG-IO* are
initially bound to synonym streams to *TERMINAL-IO*. This requirement
hampers the integration of Common Lisp with many existing and
potential operating environments.
For example, a Unix implementation is currently unable to legally
support Unix standard error output even though Common Lisp defines
*ERROR-OUTPUT* because *ERROR-OUTPUT* is required to start out bound
to the same stream as *STANDARD-OUTPUT*. A workstation environnment
which provides stream access to windows as an extension is currently
forbidden to make trace output appear in a separate window by default
because *TRACE-OUTPUT* is required to start out bound to the same
stream as *STANDARD-OUTPUT*.
Proposal (STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS):
A Common Lisp implementation is required to provide the following
initial streams. Each initial stream has a specific purpose as
defined in CLtL. This proposal redefines the initial bindings of
the streams and leaves the rest of the CLtL description unchanged.
*TERMINAL-IO*
*STANDARD-INPUT*
*STANDARD-OUTPUT*
*ERROR-OUTPUT*
*TRACE-OUTPUT*
*QUERY-IO*
*DEBUG-IO*
The initial bindings of these variables are undefined except
that:
1. They are all initially bound to open streams.
2. The streams must support input and/or output as
indicated by the variable name.
3. None of the standard streams (including *TERMINAL-IO*)
may be directed by synonym streams to another of these
stream variables (except *TERMINAL-IO*), whether
directly or by indirection via some composite stream
such as a two way stream with one of the arms being a
synonym stream.
4. Any or all of these streams may be synonyms for the
common implementation dependent stream. For example,
in an interactive Common Lisp invocation running on a
character terminal, all of the streams mentioned here
might be synonym streams (or two-way streams to synonym
streams) to a pair of hidden terminal input/output
streams maintained by the implementation.
The intent of the above rules is to ensure that it is always
safe to bind any of the above variables to another of the
above variables without unduly restricting implementation
flexibility.
Test Cases/Examples:
(PROGN
(PRINT "Output" *STANDARD-OUTPUT*)
(PRINT "Error" *ERROR-OUTPUT*))
In current Common Lisp will write:
------
Output
Error
------
With proposal *might* write:
------
Output
------
and "Error" appears somewhere else.
(LET ((*STANDARD-OUTPUT* *DEBUG-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference if *DEBUG-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference
unless the initial value of *DEBUG-IO* had been changed to a value
that did not conform the restrictions in this proposal. While no
Common Lisp implementation should do this, a user program might.
(LET ((*STANDARD-INPUT* *TERMINAL-IO*)
(*STANDARD-OUTPUT* *TERMINAL-IO*))
...)
In current Common Lisp:
Might cause a circular stream reference because *TERMINAL-IO* was
bound to a two-way stream made up of synonym streams to
*STANDARD-INPUT* and *STANDARD-OUTPUT*.
With this proposal:
Would be guaranteed not to cause a circular stream reference.
Rationale:
This proposal attempts to provide a balance between over-specifying
behavior to the point that Lisp programs can't behave like other
programs in conventional operating systems and providing enough
specification that Common Lisp programs can perform portable input and
output.
Current practice:
Lucid binds *TERMINAL-IO* to a special internal stream type. Franz
binds *TERMINAL-IO* to a special internal stream type for terminal
streams which reads from Unix standard input and writes to Unix
standard output. KCL binds *TERMINAL-IO* to a standard two-way-stream
with input from Unix standard input and output to Unix standard
output. Symbolics Genera binds *TERMINAL-IO* as appropriate for each
process, usually to a window for interactive applications or to a
stream which will conjure an interaction window on demand for
background tasks.
Cost to Implementors:
All implementations will have to change to some degree but the changes
will probably be simple and localized. All known implementations
already support the underlying streams required to implement this
proposal.
Cost to Users:
User code which depends on the strict binding hierarchy in CLtL may
have to change.
Cost of non-Adoption:
It will continue to be difficult or impossible to integrate portable
Common Lisp progams in conventional operating system environments.
Many implementations will have to continue to choose between
conforming to the standard and providing a superior user environment.
Benefits:
Implementations will be more able to match their IO behavior to their
environment and their user's expectations.
Aesthetics:
Improved because this area becomes better defined.
Discussion:
Moon says that *TERMINAL-IO* (and, by extension, *QUERY-IO*, and
*DEBUG-IO*) should fail to work in a non-interactive environment where
nothing like a terminal exists. This proposal fails to address this.
Masinter notes that:
``In many multi-processing multi-window environments,
the "initial binding" for *STANDARD-INPUT*, *QUERY-INPUT*
differs for each process.''
Pierson and Pitman support STANDARD-INPUT-INITIAL-BINDING:DEFINED-CONTRACTS.
∂11-Jul-88 0856 CL-Cleanup-mailer subtypep vagueness
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88 08:56:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA06413; Mon, 11 Jul 88 09:56:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA22689; Mon, 11 Jul 88 09:55:58 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807111555.AA22689@cdr.utah.edu>
Date: Mon, 11 Jul 88 09:55:52 MDT
Subject: subtypep vagueness
To: cl-cleanup@sail.stanford.edu
While trying to build CLX under (the original) HPCL, I've run into a problem
with the rather vague specification of when SUBTYPEP is allowed to say that
it can't determine the relationship between the two types. The particular
problem I've run into is:
(subtypep '(simple-array (unsigned-byte 8) (*)) 'sequence) => T T
(deftype foo () '(simple-array (unsigned-byte 8) (*)))
(subtypep 'foo 'sequence) => NIL NIL
Although this behavior is certainly inconvenient, my reading of CLtL
indicates that it's legitimate, since there's no statement of exactly
what cases SUBTYPEP is allowed to give up on. However, this makes
SUBTYPEP pretty hard to use in a portable way. Is there any interest
in putting together a proposal that sets out a minimum set of cases
that SUBTYPEP must be able to resolve?
-Sandra
-------
∂11-Jul-88 1023 CL-Cleanup-mailer Re: subtypep vagueness
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:23:34 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA05135; Mon, 11 Jul 88 13:19:51 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA00352; Mon, 11 Jul 88 13:23:24 EDT
Message-Id: <8807111723.AA00352@mist.UUCP>
To: sandra%cdr%cs.utah.edu@multimax (Sandra J Loosemore)
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: subtypep vagueness
In-Reply-To: Your message of Mon, 11 Jul 88 09:55:52 -0600.
<8807111555.AA22689@cdr.utah.edu>
Date: Mon, 11 Jul 88 13:23:20 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I would certainly like to see such a proposal.
∂11-Jul-88 1029 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:29:05 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA09454; Mon, 11 Jul 88 11:28:48 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA22729; Mon, 11 Jul 88 11:28:44 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807111728.AA22729@cdr.utah.edu>
Date: Mon, 11 Jul 88 11:28:42 MDT
Subject: issue BOGUS-FIXNUMS (initial draft)
To: cl-cleanup@sail.stanford.edu
Issue: BOGUS-FIXNUMS
References: CLtL p. 14, 34, 43, 231
Category: CHANGE
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums. While in many
implementations these correspond to different internal
representations, some implementations may support only a single
representation for all integers. In such a case, arbitrarily
designating some subrange of integers as "fixnums" becomes an
artificial contrivance which is more likely to confuse users than to
ensure portability of code.
Proposal: BOGUS-FIXNUMS:ELIMINATE-DISTINCTION
(1) Remove all references to the partitioning of the type INTEGER into
FIXNUM and BIGNUM. Remove FIXNUM and BIGNUM from the table of standard
type specifier symbols on page 43 of CLtL.
(2) Remove the constants MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
from the language.
(3) Introduce a new constant, MAX-INTEGER-LENGTH. This is the maximum
number of bits appearing in any integer; therefore, it is an upper
bound on the INTEGER-LENGTH function. The value can be NIL if there
are no limits short of memory availability.
Rationale:
Since CLtL does not guarantee anything about the range of fixnums
(saying only that they will *typically* be between -2**n and 2**n - 1,
for n not less than 15), any user program that uses FIXNUM or BIGNUM
declarations is already nonportable. Using these type specifiers for
discrimination is also of questionable utility in portable code. In
removing these type specifiers from the language standard, this proposal has
no effect on portability.
Current Practice:
KCL has only a single representation for integers, as do a number of
Common Lisp subsets (including XLisp and A-Lisp). Some Lisps have
more than two representations for integers; PSL, for example, has
three different representations, similar to Lisp 1.6. Franz Lisp and
Interlisp also have three different integer representations.
Implementations do not necessarily limit bignum size only by the amount of
"available memory" (which is a rather vague concept anyway). For example,
many implementations restrict the length of the bignum to be representable
in a fixed-length field.
Cost to implementors:
Slight. Implementations that support different representations for fixnums
and bignums can continue to do so and provide the type specifiers as a
compatible extension.
Cost to users:
Slight, at least in portable code. If implementors continue to
support the FIXNUM and BIGNUM type specifiers, existing (nonportable)
user code that relies on them would continue to work in those
implementations. It's possible that some portable user programs
actually use the value of MOST-POSITIVE-FIXNUM or MOST-NEGATIVE-FIXNUM
(for example, to scale fixed-point values to fit in a fixnum).
Benefits:
Removing the distinction between fixnums and bignums simplifies the
language. It reduces ambiguity in the case where there are more than
two integer representations.
Introducing a new constant to describe the maximum size of integers makes
it possible to describe an implementation's exact limitations on the range
of integers it supports. This constant would also be useful for the
description of subset implementations.
Discussion:
Addition of the MAX-INTEGER-LENGTH constant was suggested by Stan Shebs,
who supports this proposal.-------
∂11-Jul-88 1034 CL-Cleanup-mailer Re: subtypep vagueness
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:34:23 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 11 JUL 88 10:28:01 PDT
Date: 11 Jul 88 10:27 PDT
From: masinter.pa@Xerox.COM
Subject: Re: subtypep vagueness
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Mon, 11
Jul 88 09:55:52 MDT
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880711-102801-6870@Xerox>
please -- why don't you make a stab at it? Start with the cases that HPCL didn't
do that you found inconvenient for portable code.
∂11-Jul-88 1059 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 11 Jul 88 10:59:32 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA00797@EDDIE.MIT.EDU>; Mon, 11 Jul 88 13:57:24 EDT
Received: by spt.entity.com (smail2.5); 11 Jul 88 10:37:26 EDT (Mon)
To: edsel!jlm@labrea.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: Jim McDonald's message of Fri, 8 Jul 88 10:21:40 PDT <8807081721.AA15658@bhopal.lucid.com>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Message-Id: <8807111037.AA02007@spt.entity.com>
Date: 11 Jul 88 10:37:26 EDT (Mon)
From: gz@spt.entity.com (Gail Zacharias)
Date: Fri, 8 Jul 88 10:21:40 PDT
From: Jim McDonald <edsel!jlm@labrea.stanford.edu>
> I think :UP might just be a keyword, since I can't
> imagine there being more than one way of moving up.
...
Then using csh, after cd /foo/b1/b2/.., pwd will show /foo/a1/a2,
but using bsh, after cd /foo/b1/b2/.., pwd will show /foo/b1.
Right you are. Of course Unix doesn't have any syntax which would allow the
pathname itself to specify which variant it wants, but some other system
might. So this does show that it would be unwise to assume that every
implementation would be able to represent all upward motion in pathnames with
a single token such as :UP.
∂11-Jul-88 1313 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88 13:13:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA14917; Mon, 11 Jul 88 14:12:52 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA22808; Mon, 11 Jul 88 14:12:48 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807112012.AA22808@cdr.utah.edu>
Date: Mon, 11 Jul 88 14:12:47 MDT
Subject: SUBTYPEP-TOO-VAGUE (initial draft)
To: cl-cleanup@sail.stanford.edu
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, the list form of FUNCTION, or VALUES type specifiers.
(2) If a type specifier defined with DEFTYPE is passed to SUBTYPEP,
SUBTYPEP must treat it in the same way as if its expansion were passed
instead.
(3) Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
AND, OR, and NOT are messy to deal with. (MEMBER falls into the same
section but is easy to do). I don't know how one would compare
FUNCTION or VALUES type specifiers; some rules could be established to
clarify how to compare them but I don't think it would would be
particularly useful to do so.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
None.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
Item (3) appeared to be the consensus from a discussion on the
common-lisp mailing list some time ago.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
-------
∂11-Jul-88 1418 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 11 Jul 88 14:18:00 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 431776; Mon 11-Jul-88 17:16:39 EDT
Date: Mon, 11 Jul 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807111728.AA22729@cdr.utah.edu>
Message-ID: <880711171627.4.KMP@PEWEE.SCRC.Symbolics.COM>
This proposal might go over better if we replaced the feature with
another, more portable, feature addressing a similar need. eg,
FIXNUM could be left undefined as proposed, and then implementations
could support it as a non-portable extension
but also
SMALL-INTEGER could be defined as some range of integers which we
think most implementations can support efficiently (but with the
understanding that the important thing is to support it correctly
rather than efficiently). For example, maybe SMALL-INTEGER could
be defined as (INTEGER -2↑30 (2↑30)). [The specific bounds is open
to discussion, of course, I'm just proposing ``something like this''.]
As a corollary, MOST-POSITIVE-EFFICIENTLY-REPRESENTABLE-INTEGER, etc
might hold an integer (or NIL, if the concept made no sense for some
reason in a particular implementation -- eg, all numbers were bignums)
with no necessary relation to the type SMALL-INTEGER. Maybe it could
just be MOST-POSITIVE-EFFICIENT-INTEGER.
That way, people could declare known-to-be-small integers without
being concerned that some pathological implementation would screw them
by having an ultra-tiny range.
Note also that there'd be a slight two's-complement bias there, but the
alternative seems to be to offer nothing, and I'm not sure that that's
better.
Does anyone think this is worth trying to incorporate with this proposal
to make it more palatable to those who are worried that striking FIXNUM
will lose them functionality. (I don't dispute Sandra's claim that almost
no one knows how to use FIXNUM portably. There are a few, but only very
few, portable uses, and I think not enough to worry about. I'm just
concerned that people use FIXNUM because it's all we offer and that
perhaps what that really means is not that we should give up on the
feature, but rather that there's such severe need for it that we should
come up with something better.)
∂11-Jul-88 1436 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 11 Jul 88 14:36:20 PDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06788; 11 Jul 88 22:07 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 11 Jul 88 21:32:31 bst
Message-Id: <5509.8807112032@aiva.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
> Date: Mon, 11 Jul 88 11:28:42 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
Do I understand this? You are proposing to eliminate fixnums from
the language?
I would certainly oppose such a change. Even though fixnums may
differ from implementation to implementation, I want a standard
way to use them when they exist rather than allow implementations
to diverge (so that some call them fixnums, others something else,
and so on).
> Rationale:
> Since CLtL does not guarantee anything about the range of fixnums
> (saying only that they will *typically* be between -2**n and 2**n - 1,
> for n not less than 15), any user program that uses FIXNUM or BIGNUM
> declarations is already nonportable.
This depends on what you count as portable. There may be no gain
in efficiency, but the program will still work if care is taken
to check the range and in many cases even if not. Moreover, I
can know that this kind of thing is called "fixnum" and not
something else.
> Current Practice:
> KCL has only a single representation for integers,
It has two -- or three: see Franz below.
> Franz Lisp [has] three different integer representations.
You might say Franz has three, but small fixnums have the same format
as larger ones; the difference is that they live in a known part of
memory and new ones are never allocated. If you count this as three,
KCL also has three.
> Cost to users:
> Slight, at least in portable code. If implementors continue to
> support the FIXNUM and BIGNUM type specifiers, existing (nonportable)
> user code that relies on them would continue to work in those
> implementations.
I think it is a mistake to think that "nonportable" code does not count.
It is useful to have a standard way to do something even if it does not
work everywhere, and the optimizations for fixnums are important enough
that most implementations provide some.
I do not accept the argument that it doesn't matter because everyone who
provides fixnums can still provide them. If they're not in the standard,
users cannot in fact rely on them being provided in a standard way.
Indeed, if we decide to allow only standard symbols in the LISP package,
users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
FIXNUM as they can now.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂11-Jul-88 1944 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 11 Jul 88 19:44:08 PDT
Received: by labrea.stanford.edu; Mon, 11 Jul 88 19:43:23 PDT
Received: from blacksox.lucid.com by edsel id AA19205g; Mon, 11 Jul 88 17:31:13 PDT
Received: by blacksox id AA00951g; Mon, 11 Jul 88 17:27:00 pdt
Date: Mon, 11 Jul 88 17:27:00 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8807120027.AA00951@blacksox.lucid.com>
To: sandra@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 11 Jul 88 14:12:47 MDT <8807112012.AA22808@cdr.utah.edu>
Subject: SUBTYPEP-TOO-VAGUE (initial draft)
AND, OR and NOT are only messy to deal with if any of the type
specifiers involved use SATISFIES. Otherwise they are well defined.
I think you should remove AND, OR and NOT from the "exceptions list."
∂12-Jul-88 0247 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 12 Jul 88 02:46:39 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03327; 12 Jul 88 10:12 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa04851;
12 Jul 88 10:33 BST
To: sandra <@cs.utah.edu:sandra@cdr>
CC: cl-cleanup@sail.stanford.edu
In-reply-to: sandra (Sandra J Loosemore)'s message of Mon, 11 Jul 88 11:28:42 MDT <8807111728.AA22729@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Tue, 12 Jul 88 10:33:24 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
This looks like a giant step backwards. Some of us are interested in
writing efficient code. Even if some machines only have one
representation I find it hard to believe that there are not a subset
which are more efficient. Are you seriously suggesting that LISP
should counternance numbers not being arbitary precision?
Anyway KCL has fixnum, bignum and short fixnum.
==John
∂12-Jul-88 0926 CL-Cleanup-mailer package-clutter:reduce
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 09:26:29 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA25515; Tue, 12 Jul 88 09:24:27 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb (5.51/1.36)
id AA02189; Mon, 11 Jul 88 13:03:49 PDT
Date: Mon, 11 Jul 88 13:03:49 PDT
Message-Id: <8807112003.AA02189@trwrb>
To: cl-cleanup@sail.stanford.edu
Subject: package-clutter:reduce
I support this proposal.
∂12-Jul-88 1152 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 11:52:42 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 12 Jul 88 14:51:44 EDT
To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
cc: sandra <@cs.utah.edu:sandra@cdr>, cl-cleanup@sail.stanford.edu
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
In-reply-to: Your message of Tue, 12 Jul 88 10:33:24 -0000.
Date: Tue, 12 Jul 88 14:49:53 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU
Striking the FIXNUM type specifier doesn't mean fixnums cease to exist: it
just means this implementation detail is somewhat better hidden. There
would be nothing to prevent an application that currently uses FIXNUM from
doing:
(deftype fixnum () '(signed-byte 16))
Or whatever property the program was assuming that FIXNUM had.
Any compiler that can't recognize this deftype as a subtype of its internal
fixnum type (if it in fact is) is broken (not to say that there aren't lots
of broken compilers).
But I think that the issue isn't quite as clear-cut as the anti-fixnums are
making it. In many implementations, a fixnum type constraint results in a
>10x performance improvement. People tuning programs for these
implementations cannot ignore this reality, and need some kind of handle on
a "good" integer subrange.
Even if the FIXNUM type specified were flushed, the constants delimiting
the implementation fixnum range should remain. Of course, with these
constants, once can always:
(deftype fixnum () `(integer ,most-negative-fixnum ,most-positive-fixnum))
And of course, people will do this. And their programs will still run
fast, and will still run with no problem on the vast majority of
implementations with a reasonable fixnum size.
Rob
∂12-Jul-88 1253 CL-Cleanup-mailer Re: SUBTYPEP-TOO-VAGUE (initial draft)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 12:52:01 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 12 Jul 88 15:50:38 EDT
To: Eric Benson <edsel!eb@labrea.stanford.edu>
cc: sandra@cs.utah.edu, cl-cleanup@sail.stanford.edu
Subject: Re: SUBTYPEP-TOO-VAGUE (initial draft)
In-reply-to: Your message of Mon, 11 Jul 88 17:27:00 -0700.
<8807120027.AA00951@blacksox.lucid.com>
Date: Tue, 12 Jul 88 15:50:23 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8807120027.AA00951@blacksox.lucid.com>
To: sandra@cs.utah.edu
Subject: SUBTYPEP-TOO-VAGUE (initial draft)
AND, OR and NOT are only messy to deal with if any of the type
specifiers involved use SATISFIES. Otherwise they are well defined.
I think you should remove AND, OR and NOT from the "exceptions list."
I would change that to say that AND OR and NOT are only *impossible* when
they involve uses of SATISFIES. They are plenty messy otherwise. In a
compiler I am working on, I have 1500 lines of hairy and reasonably dense
code for a SUBTYPEP that only partially understands OR and AND, and doesn't
handle NOT at all. I strongly recommend that SUBTYPEP not be made too firm
until a public domain SUBTYPEP that implements the proposal is available.
How about:
(subtypep 'integer
'(or (rational * (6)) (member 6) (integer 7 *)))
It is fairly easy to see that this is true, but not so easy to see how to
to write a program to solve the general problem. It might even be a Hard
Problem, given that we have the capability to describe infinite sets.
Even Sandra's proposal may be more hairy than it is worth forcing on the
Common Lisp community. The MEMBER specifier can also be pretty perverse,
for example:
(subtypep '(integer 3 11) '(member 3 4 9 5 6 10 7 11 8 17 15)) => T, T
Any how many SUBTYPEPs correctly recognize that float types are finite?
(subtypep `(short-float 0s0 (,(* short-float-epsilon 4)))
`(member 0s0
,(* short-float-epsilon 1)
,(* short-float-epsilon 2)
,(* short-float-epsilon 3))) => T, T
Rob
∂12-Jul-88 1302 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE (initial draft)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88 13:02:03 PDT
Return-Path: <gls@Think.COM>
Received: from brigit.think.com by Think.COM; Tue, 12 Jul 88 15:04:50 EDT
Received: by brigit.think.com; Tue, 12 Jul 88 15:59:28 EDT
Date: Tue, 12 Jul 88 15:59:28 EDT
From: gls@Think.COM
Message-Id: <8807121959.AA13736@brigit.think.com>
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: edsel!eb@labrea.stanford.edu, sandra@cs.utah.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@wb1.cs.cmu.edu's message of Tue, 12 Jul 88 15:50:23 EDT <8807121858.AA09947@Think.COM>
Subject: SUBTYPEP-TOO-VAGUE (initial draft)
Date: Tue, 12 Jul 88 15:50:23 EDT
From: Rob.MacLachlan@wb1.cs.cmu.edu
...
Any how many SUBTYPEPs correctly recognize that float types are finite?
(subtypep `(short-float 0s0 (,(* short-float-epsilon 4)))
`(member 0s0
,(* short-float-epsilon 1)
,(* short-float-epsilon 2)
,(* short-float-epsilon 3))) => T, T
I see your point, but SHORT-FLOAT-EPSILON is not the right quantity here.
--Guy
∂12-Jul-88 1305 CL-Cleanup-mailer Re: SUBTYPEP-TOO-VAGUE (initial draft)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Jul 88 13:05:21 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA17539; Tue, 12 Jul 88 14:04:35 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA23562; Tue, 12 Jul 88 14:04:33 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807122004.AA23562@cdr.utah.edu>
Date: Tue, 12 Jul 88 14:04:32 MDT
Subject: Re: SUBTYPEP-TOO-VAGUE (initial draft)
To: Rob.MacLachlan@wb1.cs.cmu.edu
Cc: Eric Benson <edsel!eb@labrea.stanford.edu>, sandra@cs.utah.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: Rob.MacLachlan@WB1.CS.CMU.EDU, Tue, 12 Jul 88 15:50:23 EDT
Hmmm, I think you've convinced me to add MEMBER to the list of messy
cases after all....
-Sandra
-------
∂12-Jul-88 1544 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 12 Jul 88 15:44:43 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA07536@EDDIE.MIT.EDU>; Tue, 12 Jul 88 18:43:48 EDT
Received: by spt.entity.com (smail2.5); 12 Jul 88 18:01:06 EDT (Tue)
To: sandra%cdr@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807111728.AA22729@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft)
Message-Id: <8807121801.AA06063@spt.entity.com>
Date: 12 Jul 88 18:01:06 EDT (Tue)
From: gz@spt.entity.com (Gail Zacharias)
It is not uncommon for a program to find itself with an object which is known
to be either a small integer or, say, a string or a list. In such cases
(typep x 'fixnum) is likely to more efficient than either (typep x 'integer)
or (typep x '(integer 0 1000)), and it's an optimization that a compiler can't
do for you.
∂12-Jul-88 1555 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88 15:55:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 12 JUL 88 15:28:16 PDT
Date: 12 Jul 88 15:28 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Mon, 11
Jul 88 11:28:42 MDT
To: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880712-152816-1764@Xerox>
I can't see getting entirely rid of FIXNUMs and adding something else just
because FIXNUMs aren't really portable. I think it might be more reasonable to
be more explicit about how unportable FIXNUMs are.
Certainly implementations that have only one representation can arbitrarily
deftype FIXNUM to be SIGNED-BYTE 32 and leave it at that.
To put it in terms of the proposal: I don't think that the problem statement as
written establishes that there is a significant problem with the language; there
may be a problem with CLtL and with CL programming texts and lots of the CL code
running around, but I think it is OK for the language to have some portable way
of talking about the "most efficient number range". All computers that I know
about have word sizes.
I certainly would like to discourage programmers from using FIXNUM for
discrimination when they really don't mean it, and from using FIXNUM
declarations when they really mean a given number range, but I don't think
taking FIXNUM out of the language is the proper way to do it.
I don't see how MAX-INTEGER-LENGTH has anything to do with the problem as
stated. I think it is a separate proposal, if you want to allow for limits on
bignum size.
∂12-Jul-88 1630 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jul 88 16:29:54 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 12 JUL 88 16:01:35 PDT
Date: 12 Jul 88 16:00 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 12 Jul 88 18:01:06
EDT (Tue)
To: gz@spt.entity.com (Gail Zacharias)
cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
Message-ID: <880712-160135-1829@Xerox>
Sigh, that's just the kind of code that is very non-portable and that I'd like
to discourage programmers from writing. I've tried to import stuff from a CL
that had 31 bit FIXNUMs into a system that had 17-bit FIXNUMs and, out of sheer
laziness, they said FIXNUM when they really meant (signed-byte 24).
∂13-Jul-88 0853 CL-Cleanup-mailer an alternate BOGUS-FIXNUMS proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jul 88 08:53:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12244; Wed, 13 Jul 88 09:53:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA24171; Wed, 13 Jul 88 09:52:32 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807131552.AA24171@cdr.utah.edu>
Date: Wed, 13 Jul 88 09:52:31 MDT
Subject: an alternate BOGUS-FIXNUMS proposal
To: cl-cleanup@sail.stanford.edu, gz@spt.entity.com (Gail Zacharias)
In-Reply-To: gz@spt.entity.com (Gail Zacharias), 12 Jul 88 18:30:10 EDT (Tue)
Gail Zacharias has suggested an alternate proposal on this issue. The
relevant parts are:
> Proposal: BOGUS-FIXNUMS:SET-MINIMUM
>
> (1) Require that (SIGNED-BYTE 15) must be a subtype of FIXNUM.
>
> (2) Specify that MOST-POSITIVE-FIXNUM and/or MOST-NEGATIVE-FIXNUM may be
> NIL to indicate no limit aside from any placed on the size of integers.
> That is, the FIXNUM type is equivalent to
> `(INTEGER ,(OR MOST-NEGATIVE-FIXNUM '*) ,(OR MOST-POSITIVE-FIXNUM '*))
>
> Implementations which do not have fixnums (or do not wish to advertise them
> as such) should make the FIXNUM type be the same as INTEGER and set the
> MOST-POSITIVE/NEGATIVE-FIXNUM constants to NIL.
>
> Implementations which have fixnums of less than 15 bits would become
> implementations without fixnums. They would have to make FIXNUM be the
> same as INTEGER and pick a different name for their small integers.
> The efficient integers of such implementations cannot be taken advantage of
> by portable programs by means of FIXNUM declarations.
I suppose a proposal along these lines would be a better than the
status quo. However, I do see some problems:
- It does not address the issue of what happens to the BIGNUM type
specifier. If it remains in the language, are BIGNUM and FIXNUM still
required to be disjoint? If an implementation has only a single
representation for integers and FIXNUM == INTEGER, would the set of
BIGNUMs be empty? Or would it be similar to how the different types
of floats are handled if an implementation does not support all 4
distinct representations?
- Programmers would still be able to put FIXNUM declarations in their
code, but under this proposal FIXNUMs would not necessarily guarantee
the most efficient representation (which appears to be the main reason
why people are so anxious to preserve the FIXNUM type in the first
place).
- Forcing users to DEFTYPE their own integer subrange types instead
would encourage better use of data abstraction. I've noticed that
Lisp programs are typically much sloppier about this than programs
written in strongly typed languages such as C or Pascal.
Also, note that if users specify a smaller subrange of integers than
the nominal FIXNUM size in their declarations, it may be possible to
get even more improvements in performance. For example, a Lisp
implementation on a M68000 typically sizes fixnums to fit in a 32-bit
longword, but if enough type information is available to deduce that
the integers will fit in 16 bits (including perhaps 2 or 3 low tag
bits), it would be possible to use the significantly faster word-sized
arithmetic operations instead of longword operations.
-Sandra
-------
∂13-Jul-88 1221 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 13 Jul 88 12:19:23 PDT
Received: from aiva.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07416; 13 Jul 88 19:54 BST
From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 13 Jul 88 20:16:02 bst
Message-Id: <847.8807131916@aiva.ed.ac.uk>
To: gz%spt.entity.com@NSS.Cs.Ucl.AC.UK, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: an alternate BOGUS-FIXNUMS proposal
Cc: cl-cleanup@sail.stanford.edu
Date: Wed, 13 Jul 88 09:52:31 MDT
From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Gail Zacharias has suggested an alternate proposal on this issue.
> I suppose a proposal along these lines would be a better than the
> status quo. However, I do see some problems:
I don't mind proposals that make fixnums more portable. Do you still
think they should be eliminated instead? Perhaps we should look at
what languages like C say about "short", "int", and "long". (Very
little is promised, as I recall.)
> - Forcing users to DEFTYPE their own integer subrange types instead
> would encourage better use of data abstraction. I've noticed that
> Lisp programs are typically much sloppier about this than programs
> written in strongly typed languages such as C or Pascal.
Well, I for one do not want to figure out exactly what range I need in
every case. And in some cases I may not know an exact range. What I
want is more or less soemthing that says "give me an int (as in C,
say), not a BIGNUM".
I'm not sure just what aspects of C and Pascal programs you have in
mind. There are certainly many programs that use "int" or "long", and
those are analogous to FIXNUM, not to explicit ranges of integers or
numbers of bits.
-- Jeff
∂13-Jul-88 1445 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Jul 88 14:45:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23663; Wed, 13 Jul 88 15:42:56 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA24370; Wed, 13 Jul 88 15:42:54 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807132142.AA24370@cdr.utah.edu>
Date: Wed, 13 Jul 88 15:42:51 MDT
Subject: Re: an alternate BOGUS-FIXNUMS proposal
To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: gz%spt.entity.com@nss.cs.ucl.ac.uk, sandra <sandra%cdr@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Wed, 13 Jul 88 20:16:02 bst
> From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Date: Wed, 13 Jul 88 20:16:02 bst
>
> Perhaps we should look at
> what languages like C say about "short", "int", and "long". (Very
> little is promised, as I recall.)
>
> I'm not sure just what aspects of C and Pascal programs you have in
> mind. There are certainly many programs that use "int" or "long", and
> those are analogous to FIXNUM, not to explicit ranges of integers or
> numbers of bits.
Yes, people do declare things as "int" in C code without giving a
great deal of thought to how big an "int" really is. But in my mind,
not being guaranteed anything about integer sizes in C (and not being
able to define subrange types as you can in Pascal) is a misfeature.
I don't think its presence in C is a valid justification for including
it in Lisp.
An example of a portable C program that I'm familiar with is the MG
text editor. It runs on 8 or 9 different configurations (3 of which I
have personally hacked on), including some machines where ints are 16
bits and longs 32, some where both ints and longs are both 32 bits,
and I believe one where ints are 32 and longs are 64. We define
things like the integer type to use for indexing into a region (that
you really want to be 32 bits, but that might be either int or long)
with #typedef's in a system-specific include file. Likewise the size
of integer that represents a keystroke (12 bits) might need to be
defined as either a short or int. We've found that portability
problems are almost invariably due to code that violates the data
abstraction by doing things like declaring a variable that is used to
index into a region as "int" instead of "RSIZE", or assuming that int
and long are the same size.
-Sandra
-------
∂13-Jul-88 1543 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Jul 88 15:43:37 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA04393@EDDIE.MIT.EDU>; Wed, 13 Jul 88 18:41:56 EDT
Received: by spt.entity.com (smail2.5); 13 Jul 88 18:22:03 EDT (Wed)
To: Masinter.pa@Xerox.COM
Cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 12 Jul 88 16:00 PDT <880712-160135-1829@Xerox>
Subject: issue BOGUS-FIXNUMS (initial draft)
Message-Id: <8807131822.AA09967@spt.entity.com>
Date: 13 Jul 88 18:22:03 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)
Date: 12 Jul 88 16:00 PDT
From: Masinter.pa@Xerox.COM
Sigh, that's just the kind of code that is very non-portable and that I'd
like to discourage programmers from writing. I've tried to import stuff
from a CL that had 31 bit FIXNUMs into a system that had 17-bit FIXNUMs
and, out of sheer laziness, they said FIXNUM when they really meant
(signed-byte 24).
It's only non-portable if used on values which are not guaranteed to to be
within the FIXNUM range. If FIXNUMs were guaranteed to be at least
(signed-byte 24), it would be a perfectly valid program. Since they're not,
you just had the misfortune of working with buggy code. Buggy code can be
written using all sorts of otherwise-useful CL constructs.
The problem is of course that currently nothing is guaranteed to be in the
fixnum range, so even programs that use FIXNUM for numbers between -1 and
1 are nominally buggy. I think the solution is to guarantee some reasonable
range and be done with it.
∂14-Jul-88 1146 CL-Cleanup-mailer Re: an alternate BOGUS-FIXNUMS proposal
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 14 Jul 88 11:42:40 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06067; 14 Jul 88 19:12 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 14 Jul 88 19:36:00 BST
Message-Id: <13739.8807141836@subnode.aiai.ed.ac.uk>
To: sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: an alternate BOGUS-FIXNUMS proposal
Cc: cl-cleanup@sail.stanford.edu
Sandra:
Forcing users to DEFTYPE their own integer subrange types instead
would encourage better use of data abstraction. I've noticed that
Lisp programs are typically much sloppier about this than programs
written in strongly typed languages such as C or Pascal.
Me: There are certainly many programs that use "int" or "long", and
those are analogous to FIXNUM, not to explicit ranges of integers
or numbers of bits.
Sandra:
Yes, people do declare things as "int" in C code without giving a
great deal of thought to how big an "int" really is. But in my mind,
not being guaranteed anything about integer sizes in C (and not being
able to define subrange types as you can in Pascal) is a misfeature.
I don't think its presence in C is a valid justification for including
it in Lisp. [Followed by example of program that avoids using int or
long directly by using system-specific typedefs.]
My point was that C (and Pascal) programs do use "int", and that this is
analogous to FIXNUM. While some C programs take more care (if they are
concerned about portability to a wide range of machines), so do some Lisp
programs. I do not agree that C programs typically show more care than
Lisp programs about this particular issue (though they must, of course, be
more careful about types in general): a great many C programs simply use
"int" or "long". Nor it is the case that C and Pascal *force* users to
define their own integer subrange types. And, well, all this is not to
show that "int" in C justifies FIXNUM in Lisp but only that your argument
in favor of "forcing users", etc. does not have the support from C and
Pascal that you suggest.
One the contrary, C and Pascal show that "int" is useful and that forcing
users to define subranges is not necessary. This point is valid, because
is shows that such ill-defined types are nonetheless useful. Perhaps it
would not be enough to justify adding FIXNUM to Lisp, but since you are
suggesting a change to CL, the burden of proof is on you to show that
FIXNUM should be removed and that its utility is outweighed by other
factors.
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂14-Jul-88 1538 CL-Cleanup-mailer Re: various DEFSTRUCT issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Jul 88 15:38:10 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 JUL 88 15:21:51 PDT
Date: 14 Jul 88 15:22 PDT
From: masinter.pa@Xerox.COM
Subject: Re: various DEFSTRUCT issues
In-reply-to: Barry Margolin <barmar@Think.COM>'s message of Thu, 30 Jun 88 00:10
EDT
To: Barry Margolin <barmar@Think.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880714-152151-6402@Xerox>
My belief is that we should say that it is an error to have two slots with
string-equal slot names, and that it is an error to redefine a structure, in
that slot-accessors for structures are presumed to be declared "inline". If
users want more flexibility than that, they should use defclass.
Given that we have defclass and CLOS, I'm leaning toward allowing maximal
performance hacking by implementations using vanilla DEFSTRUCT. So requiring
implementations to allow things they don't currently allow (even though some
implementations might allow them) seems like it is going in the wrong direction.
∂14-Jul-88 2214 CL-Cleanup-mailer BOGUS-FIXNUMS, again
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Jul 88 22:14:39 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA06686; Thu, 14 Jul 88 23:14:13 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA25613; Thu, 14 Jul 88 23:14:09 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807150514.AA25613@cdr.utah.edu>
Date: Thu, 14 Jul 88 23:14:07 MDT
Subject: BOGUS-FIXNUMS, again
To: cl-cleanup@sail.stanford.edu
Since it appears that nobody besides me (and Stan) likes my previous
proposal on this issue and that I'll have to come up with something
less radical that is more acceptable to the rest of the committee, I
thought it would be useful to enumerate some of the possibilities. I
realize there are still two other issues which would still have to be
addressed when turning any of these into a real proposal, namely
whether to retain MOST-BLETCHEROUS-FIXNUM :-), and whether the BIGNUM
type specifier should remain and whether it must still be a non-empty
set which is disjoint from FIXNUM.
#0 (what CLtL says):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined but nothing is said about its
range.
- FIXNUMs are required to have a more efficient representation than
non-FIXNUMs.
#1 (my original proposal):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier goes away.
- user-defined integer subrange types use the most efficient
representation possible in a given implementation.
#2 (Gail Zacharias's counter-proposal):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined to be a superset of
(SIGNED-BYTE n), for some value of "n" which has yet to be
decided but that we all agree upon.
- FIXNUMs are not required to coincide with or be a subset of the
set of integers which are represented most efficiently.
#3 (change CLtL's "typically" to a firm requirement):
- there is no particular type specifier defined for "small integers".
- FIXNUMs must be a supertype of (SIGNED-BYTE n).
- FIXNUMs are defined to be the set of integers which are represented
most efficiently.
#4 (dumb, but here for completeness):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined to be equivalent to
(SIGNED-BYTE n).
- FIXNUMs are required to be a subset of the integers which are
represented most efficiently.
#5: (Kent Pitman's suggestion):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the FIXNUM type specifier goes away.
- nothing is guaranteed about the efficiency of representation of
SMALL-INTEGERs.
#6 (similar to #3):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the set of FIXNUMs is required to be a superset of SMALL-INTEGERs.
- FIXNUMs are defined as the set of integers with the most efficient
representation. (This implies that SMALL-INTEGERS are also
guaranteed to be efficient.)
#7 (a cross between #0 and #5):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the FIXNUM type specifier remains but the range of FIXNUMs is left
undefined, as is the relationship between FIXNUM and SMALL-INTEGER.
- FIXNUMs are defined as the set of integers with the most efficient
representation. Nothing is guaranteed about the efficiency of
SMALL-INTEGERs.
Comments, anyone?
-Sandra
-------
∂15-Jul-88 0013 CL-Cleanup-mailer an alternate BOGUS-FIXNUMS proposal
Received: from rutgers.edu ([128.6.21.9]) by SAIL.Stanford.EDU with TCP; 15 Jul 88 00:13:30 PDT
Received: by rutgers.edu (5.59/1.15) with UUCP
id AA08860; Fri, 15 Jul 88 01:42:49 EDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA01559@EDDIE.MIT.EDU>; Wed, 13 Jul 88 23:06:58 EDT
Received: by spt.entity.com (smail2.5); 13 Jul 88 20:29:39 EDT (Wed)
To: sandra%cdr@cs.utah.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 13 Jul 88 09:52:31 MDT <8807131552.AA24171@cdr.utah.edu>
Subject: an alternate BOGUS-FIXNUMS proposal
Message-Id: <8807132029.AA10252@spt.entity.com>
Date: 13 Jul 88 20:29:39 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Date: Wed, 13 Jul 88 09:52:31 MDT
- It does not address the issue of what happens to the BIGNUM type
specifier.
I wouldn't be adverse to removing BIGNUM as a type specifier altogether.
- Programmers would still be able to put FIXNUM declarations in their
code, but under this proposal FIXNUMs would not necessarily guarantee
the most efficient representation (which appears to be the main reason
why people are so anxious to preserve the FIXNUM type in the first
place).
It would guarantee an efficient representation in all cases where it can be
reasonably expected to do so. That is, in all implementations which have a
sufficiently large range of efficient integers.
Also, note that if users specify a smaller subrange of integers than
the nominal FIXNUM size in their declarations, it may be possible to
get even more improvements in performance.
That's right. Users can always take the extra time and effort needed to do a
more detailed range analysis in especially critical sections of code.
Use of FIXNUM's is not always prompted by programmers' laziness in analyzing
their code. The problem is that in those implementations which do support
fixnums, the efficiency difference between fixnums and bignums is usually
fairly large. It's large enough that users are willing to structure their
code to take note of it. Different algorithms (e.g. different space/speed
tradeoffs) might be appropriate for fixnums and bignums. In Macsyma, there
are a number of instances where an argument is checked for being a fixnum,
and different code is used if it is (actually it's often the same code,
but full of fixnum declarations for all the intermediate results). This
is not something that can be done with range declarations. The following piece
of code is also from Macsyma:
(DO ((I 0 (1+ I))
(P MOST-POSITIVE-FIXNUM (NEWPRIME P)))
((= I 20.)))
This makes a table of the 20 largest primes which fit in a fixnum. The table
is used to good effect by various algorithms within Macsyma. Do you really
wish to disallow these kinds of optimizations?
Common Lisp goes to some trouble to provide for the needs of people writing
serious numerical floating point code. I think recognizing the (possibility
of the) FIXNUM/BIGNUM distinction is the minimum that can be done for people
writing serious numerical integer code. There may be a problem with the more
"casual" use of FIXNUM declarations for loop counters and such, but I don't
think that the way to address that problem is to pretend the distinction
doesn't exist.
∂15-Jul-88 0110 CL-Cleanup-mailer re: issue BOGUS-FIXNUMS
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 15 Jul 88 01:10:48 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.28)
id AA02152; Fri, 15 Jul 88 01:08:33 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb (5.51/1.36)
id AA07355; Thu, 14 Jul 88 12:51:45 PDT
Date: Thu, 14 Jul 88 12:51:45 PDT
Message-Id: <8807141951.AA07355@trwrb>
To: cl-cleanup@sail.stanford.edu
Subject: re: issue BOGUS-FIXNUMS
I believe it is imperative for Common Lisp to support a portable means
of declaring the range of integers to be handled ina particular operation
is within that range efficiently supported by the underlying hardware
architecture. This is what I mean when I say (declare (fixnum x)) in a
program. I understand that this limits the portability or usefulness of
my program after porting. But I believe this limitation is more funda-
mentally imposed by the underlying hardware architecture than by my
fixnum declaration -- the performance of operations involving "fixnums"
is critical to many programs.
When a Common Lisp provides only one integer representation, that may
limit the portability of my program, depending on the representation.
I may need large range; I may need the fastest possible integer operations
restricted to the range efficiently supported. A representation that
limits range to a fixed range is a bogus bignum implementation, in my book.
A representation that does not take advantage of fast integer arithmetic
performance for a restricted range of integers has a bogus fixnum implementa-
tion, similarly. That is assuming, of course, that there is only that one
representation.
When a Common Lisp provides more than two representations, it is also
limiting portability in some way. Let's say there are three representations.
Let's further say that one corresponds to the accepted definition of fixnum
and another to the accepted definition of bignum. Then use of the third
will likely limit portability, if my declarations are intended to be for
sake of efficiency. Use of (declare ((integer n0 n1) x)), could, of
course, be useful and portable given three representations. But they
would not be used for the same purpose as a fixnum or bignum declaration.
I guess my point is that the portability of my program is something I
determine based on the power of the hardware architecture and the quality
of the Lisp implementation. Given that the architecture is powerful
enough (has a wide enough word size, for example), I can port to it.
But my fixnum declarations are for performance. If it were not important
for that declaration to be made for efficiency, I likely wouldn't make it
at all. This may reflect a difference in philosophy between those who
declare everything for sake of program clarity or readability and me, I
suspect. Those who make declarations for other-than-performance likely find
my fixnum declarations utterly detestable. I'm not arguing one philosphy
versus the other; I assuming a sizeable set of programmers who use declara-
tions similarly to how I use them. Taking away the fixnum/bignum distinction
takes away a valuable and well-used tool.
--Joe
∂15-Jul-88 0555 CL-Cleanup-mailer Issue: BOGUS-FIXNUMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Jul 88 05:55:11 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 433676; Fri 15-Jul-88 08:54:52 EDT
Date: Fri, 15 Jul 88 08:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: BOGUS-FIXNUMS
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880715085441.8.KMP@PEWEE.SCRC.Symbolics.COM>
Perhaps the real cause of trouble here is that we have only one type, FIXNUM,
for two purposes -- (a) `machine precision' of either non-portable or
hyper-optimized programs like Macsyma (b) `small integers' desiring
efficiency.
The reason I suggested SMALL-INTEGER is that I think that's what some people
really want to say. I'm much less strong on elminating FIXNUM than I am on
providing a useful alternative. As it is now, if you want efficient code but
also want it to be portable, you have nothing to say beyond a cumbersome
signed-byte or bounded integer range. Just as we provide the `common'
sequence operations because it saves everyone from writing them over and
over, so too we should provide the common declarations to save everyone from
writing them.
I think what Sandra is saying is not argued. FIXNUM declarations are very
seldom portable. Even in Macsyma, the alternate fixnum declared code might
sometimes be gone into on the basis of inputs being fixnums, sometimes not
worrying as carefully as it might about whether intermediate values or
outputs will all be fixnums. And every now and then you might lose unless
you've done some careful checking. GZ, JDalton, etc. are saying they're
willing to do such checking sometimes.
The problem is that naive users will see FIXNUM and mentally relate it to
small integers when it's really quite different. Surely, I can imagine such
a user saying, there is at least the concept of a small integer. Since
there's only one type even remotely like that, it must be it. In fact, that
would be a wrong assumption. My reading of CLtL says the fixnum subrange
need not even include zero. It might be (INTEGER 5 25), for example. There
might, therefore, be integers smaller than FIXNUMs. We might want to just
plain fix that. It might also include no numbers (though that leaves an
implementation in a quandry about what to put in MOST-POSITIVE-FIXNUM, etc.)
I think some CDC CL had this problem. As best I remember from a manual I saw
a couple years ago, they had set the MOST-xxx vars to NIL because they had
the same representation for all numbers and had chosen them to either all
be fixnums or all be bignums, I don't recall. All of this is bound to confuse
a novice who may just be seeking a simple, efficient type declaration.
My revised view is that we leave FIXNUM and its associated vars be, and
add SMALL-INTEGER. We should choose the range of SMALL-INTEGER such that,
then clearly document that, SMALL-INTEGER is a portable concept which
might lead to inefficiency in an occasional implementation, but in most
implementations it will be suitably fast. We should document that FIXNUM
is intended to denote an implementation-specific type which is not
portable, but which is useful in certain applications, like Macsyma, which
have need to take the fullest advantage of whatever machine they're on, even
at the price of dealing more carefully with portability issues.
I think the availability of a pre-defined and usefully sized type such as
SMALL-INTEGER will make this explanation of FIXNUM much more palatable.
I would remove the type BIGNUM. I think everyone expects it to mean
(AND INTEGER (NOT FIXNUM)) anyway. I bet any implementation where it doesn't
mean this violates user expectations. Given that, one could just DEFTYPE
it for compatibility if it was really used heavily in some particular case.
∂17-Jul-88 0820 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Jul 88 08:20:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA03839; Sun, 17 Jul 88 09:19:07 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA23357; Tue, 12 Jul 88 09:08:27 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807121508.AA23357@cdr.utah.edu>
Date: Tue, 12 Jul 88 09:08:25 MDT
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
To: cl-cleanup@sail.stanford.edu
Cc: KMP@stony-brook.scrc.symbolics.com,
jeff%aiva.edinburgh.ac.uk@nss.cs.ucl.ac.uk,
jpff%maths.bath.ac.uk@nss.cs.ucl.ac.uk
In-Reply-To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK, Tue, 12 Jul 88 10:33:24 BST
Well, I thought this issue would generate some flamage.... But before this
gets any farther, let me make one thing clear: This proposal *is* *not*
(read my lips! IS NOT!) an attempt to do away with either efficient "fixnum"
arithmetic or arbitrary precision arithmetic! It is merely an attempt to
get rid of some unfortunate and nonportable terminology from the language
standard.
> Date: Mon, 11 Jul 88 17:16 EDT
> From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
>
> This proposal might go over better if we replaced the feature with
> another, more portable, feature addressing a similar need. eg,
>
> SMALL-INTEGER could be defined as some range of integers which we
> think most implementations can support efficiently (but with the
> understanding that the important thing is to support it correctly
> rather than efficiently). For example, maybe SMALL-INTEGER could
> be defined as (INTEGER -2↑30 (2↑30)). [The specific bounds is open
> to discussion, of course, I'm just proposing ``something like this''.]
Users can already define such a type (or types) on their own. This technique
is used quite extensively in CLX, where there are about a dozen types
defined like:
(deftype int8 () '(signed-byte 8))
(deftype card16 () '(unsigned-byte 16))
(deftype array-index () `(integer 0 ,array-dimension-limit))
Unlike "fixnum", these type specifiers have uniform semantics across all
implementations. One would hope that in those implementations where they
are subtypes of "fixnum", the compiler would be smart enough to recognize
them as such.
(As an aside, there is a precedent for doing this in other languages
as well. Many Pascal compilers, for example, only have one size of
integer that is allocated if you just say "integer". But, if you
define a subrange type like 0..255 instead, they'll only allocate an
8-bit byte for it.)
> From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> Date: Mon, 11 Jul 88 21:32:31 bst
>
> Even though fixnums may
> differ from implementation to implementation, I want a standard
> way to use them when they exist rather than allow implementations
> to diverge (so that some call them fixnums, others something else,
> and so on).
Having a standard name is of little use unless it is tied to some
standard semantics. The problem is that there is no guarantee what
you get when you say "fixnum". There is currently no absolute
prohibition against defining the range of fixnums to be something like
100,000 to 100,010. If you want "small integer", then by all means
define your own small integer type using DEFTYPE. That way you're
guaranteed to have it mean exactly the same thing in all
implementations.
> I do not accept the argument that it doesn't matter because everyone who
> provides fixnums can still provide them. If they're not in the standard,
> users cannot in fact rely on them being provided in a standard way.
> Indeed, if we decide to allow only standard symbols in the LISP package,
> users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> FIXNUM as they can now.
Why not just import the appropriate symbol into the package you're using
once, and be done with it?
> Date: Tue, 12 Jul 88 10:33:24 BST
> From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>
> This looks like a giant step backwards. Some of us are interested in
> writing efficient code. Even if some machines only have one
> representation I find it hard to believe that there are not a subset
> which are more efficient. Are you seriously suggesting that LISP
> should counternance numbers not being arbitary precision?
Once again, I AM NOT PROPOSING TO GET RID OF ARBITRARY PRECISION
ARITHMETIC. If your implementation supports a range of small integers
that are more efficient than larger integers, there is already a portable
way to declare them as such.
To draw an analogy, small bignums are likely to be considerably faster and
more efficient than large bignums. Should we assign a special name to
bignums with less than N "bigits" simply because they're faster than bignums
that are larger than that? How useful would having such a special name be
when both N and the size of the "bigit" vary from implementation to
implementation?
> Anyway KCL has fixnum, bignum and short fixnum.
It appears I was misinformed on this point -- I was under the impression
that KCL boxed all integers and simply preallocated a range of small
integers.
-Sandra
-------
∂18-Jul-88 0914 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88 09:09:22 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04367; 18 Jul 88 16:31 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 18 Jul 88 16:52:03 BST
Message-Id: <2479.8807181552@subnode.aiai.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
Cc: jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>
> Date: Tue, 12 Jul 88 09:08:25 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
What I want to establish is: [1] Fixnums are about as useful as, say,
int or long in C (or if not can be made so rather than be eliminated),
In KCL, fixnums can actually be compiled as ints. [2] It's nice to have
a standard name for efficient integers, and a standard name has to be in
the standard. [3] Explicit subranges are not necessarily efficient and
are often less convenient to use.
Moreover, GZ has provided some examples from Macsyma that show that
fixnums can be used with a considerable degree of portability even as
now defined.
In short, the argument for eliminating fixnums seems to be based on an
overemphasis on one aspect of portability rather than a consideration
of what programmers actually do and want.
> > From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> > Date: Mon, 11 Jul 88 21:32:31 bst
> >
> > Even though fixnums may differ from implementation to
> > implementation, I want a standard way to use them when they exist
> > rather than allow implementations to diverge (so that some call
> > them fixnums, others something else, and so on).
>
> Having a standard name is of little use unless it is tied to some
> standard semantics. The problem is that there is no guarantee what
> you get when you say "fixnum". There is currently no absolute
> prohibition against defining the range of fixnums to be something
> like 100,000 to 100,010.
Well, then perhaps int and long in C are of "little use". They are
not guaranteed to be the same size everywhere.
Note too that your argument is for reforming fixnums, not for
eliminating them, and I am not arguing against reform.
> If you want "small integer", then by all means define your own small
> integer type using DEFTYPE. That way you're guaranteed to have it
> mean exactly the same thing in all implementations.
You may want it to mean "exactly the same thing" (meaning exactly the
same size); that is not what I am asking for.
Besides I don't want a small integer, I want an efficient one. A
subrange is not guaranteed to be efficient, and so does not replace
FIXNUM.
> > I do not accept the argument that it doesn't matter because everyone who
> > provides fixnums can still provide them. If they're not in the standard,
> > users cannot in fact rely on them being provided in a standard way.
Note that your response about packages below does not answer this.
> > Indeed, if we decide to allow only standard symbols in the LISP package,
> > users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> > FIXNUM as they can now.
> Why not just import the appropriate symbol into the package you're using
> once, and be done with it?
This is still not providing fixnums in a standard way. I still have
to add some conditional code for each implementation.
> > Date: Tue, 12 Jul 88 10:33:24 BST
> > From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
> If your implementation supports a range of small integers
> that are more efficient than larger integers, there is already a portable
> way to declare them as such.
The range gets ported, but the efficiency may not. Fixnums work
adequately over a wide range of implementations without requiring
implementation-specific customization of my types. I am even willing to
have some programs not work in implementations that have a sufficiently
losing notion of fixnums, just as I am willing to do this in other
langauges.
> To draw an analogy, small bignums are likely to be considerably faster and
> more efficient than large bignums. Should we assign a special name to
> bignums with less than N "bigits" simply because they're faster than bignums
> that are larger than that?
That we do not want a name for every class of more efficient number
does not show we do not want a name for any such class.
Moreover, compilers can (or at least do) get more in the way of
optimization from fixnums than they would from "small bignums".
> It appears I was misinformed on this point -- I was under the impression
> that KCL boxed all integers and simply preallocated a range of small
> integers.
It does "box" all integers (though fixnum declarations may avoid this in
compiled code). But the representation of fixnums is simpler than
that for bignums. It is very much like Franz in this respect.
-- Jeff
∂18-Jul-88 1345 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 13:44:55 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 18 Jul 88 16:42:31 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Fri, 01 Jul 88 19:57:00 -0400.
<880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Mon, 18 Jul 88 16:42:01 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
This proposal to use case to control the canonicalization of case in
pathname components looks to me like it would cause confusion and paralysis
of truly awesome propotions. For that reason, I am strongly opposed to
this proposal in its current form.
If we need a way to canonicalize the case of various pathname fields, maybe
we should have a CANONICALIZE-CASE function that takes a string and a
file-system type and does the proper case-conversion.
-- Scott
∂18-Jul-88 1403 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Jul 88 14:03:19 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434787; Mon 18-Jul-88 17:02:47 EDT
Date: Mon, 18 Jul 88 17:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM>
Can you elaborate on the kind of ``confusion and paralysis of truly
awsome proportions'' you expect?
Can you also give a couple examples of what you consider portable
uses of the current paradigm which do not involve the use of READ-LINE
in order to obtain a namestring in the first place?
My point is that if every portable use of MAKE-PATHNAME must look like
(MAKE-PATHNAME :DIRECTORY (MAPCAR #'CANONICALIZE-CASE '("JOE" "TOOLS"))
:NAME (CANONICALIZE-CASE "FOO" *LOCAL-FS*)
:TYPE (CANONICIALIZE-CASE "LISP" *LOCAL-FS*))
then what's the point?
I think the examples I put forth were simple and compelling and I would
like to see some equally compelling -- but most importantly, concrete --
arguments of how such lossage is likely to occur. The only cases I can
imagine causing problems are cases where people insist on programming in
new-CL without reading the documentation. I don't mind designing languages
to take into account naive users (normal, thinking people who have
read the documentation) but I do mind designing languages to take into
account ignorant users (people who believe their own personal prejudices
and intuitions should take precedence over a carefully reasoned and
thoroughly documented theory).
Do you have a technical objection to the proposal on the table? The pathname
system from which I took the idea for this proposal is one of very few I
know of which has tried this approach and demonstrated it to be workable in
the face of numerous operating systems. Frankly, the only comments I've ever
heard numerous users of the Symbolics pathname system were ones of astonishment
at how well that aspect of the lisp machine pathname system works. So it
seems to me that the facts are in direct opposition to your ``doom and gloom''
prediction. Do you contest this claim or practical experience to the contrary
which you would like to share?
Does anyone else have any opinion on this issue? I think the experience both
of users who have tried to port programs between radically different file
systems, and of implementors who support simultaneous interfaces to multiple,
very different file systems would be of interest. I think this is a
tremendously important issue and deserves considerable thought.
∂18-Jul-88 1433 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Jul 88 14:33:27 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 434816; Mon 18-Jul-88 17:32:09 EDT
Date: Mon, 18 Jul 88 17:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
To: sandra%cdr@cs.utah.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718173159.5.KMP@PEWEE.SCRC.Symbolics.COM>
The problem I have with being told I should DEFTYPE my own SMALL-INTEGER is the
following:
I believe that one of Lisp's greatest strengths (which is one of the things setting
it apart from Pascal, for example) is not just that it has the potential for
representing and defining things, but that it is gutsy enough to actually predefine
a set of things which people are likely to find useful.
Most languages can, for example, represent their own programs. eg, you could create
a PL/I program which constructed representations of other PL/I programs. The
important thing about Lisp is not that it can represent itself, but that there
is a common agreement about -how- to do such representation, so that non-cooperating
parties can agree.
I think this is at the heart of why jpff and jeff don't want to get rid of fixnum.
I'm happy with that.
It's just a pain for programmers to have to write the DEFTYPE. DEFTYPE is hard to
understand for a naive user. Using it involves at least a strong understanding of
the type system, a thorough enough knowledge of CL to know that DEFTYPE exists at
all, and a knowledge of how to use cons/list/backquote well enough to construct
a new specifier. On the other hand, if some arbitrary type were predefined, then
many people who understood only numerical programming could just go ahead and use
it. It might not serve all their needs, but it would get them started. And it would
get them used to the idea of a restricted range. Once you know the range is
-2↑16 to 2↑16 or whatever, it's easier to know to ask how to declare a different
range than it is to know to ask how to restrict the range if all you know is that
there is an unrestricted range initially.
Further, if we can agree on any range which makes us generally happy for a number
of small programs, then even if it's not -guaranteed- that it will be efficient,
then it will be -likely- that it will be efficient if only because people tend
to optimize things that have names much more than they optimized things you have
to compose, on the assumption that it's easier for users to trip over named things
and so such optmizations will have higher visibility.
So I think that saying that I should define my own type SMALL-INTEGER doesn't
satsify my need and I stand by my suggestions of my previous message.
∂18-Jul-88 1552 CL-Cleanup-mailer Re: issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88 15:49:52 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04367; 18 Jul 88 16:31 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Mon, 18 Jul 88 16:52:03 BST
Message-Id: <2479.8807181552@subnode.aiai.ed.ac.uk>
To: cl-cleanup@sail.stanford.edu, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: issue BOGUS-FIXNUMS (initial draft)
Cc: jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>
> Date: Tue, 12 Jul 88 09:08:25 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
What I want to establish is: [1] Fixnums are about as useful as, say,
int or long in C (or if not can be made so rather than be eliminated),
In KCL, fixnums can actually be compiled as ints. [2] It's nice to have
a standard name for efficient integers, and a standard name has to be in
the standard. [3] Explicit subranges are not necessarily efficient and
are often less convenient to use.
Moreover, GZ has provided some examples from Macsyma that show that
fixnums can be used with a considerable degree of portability even as
now defined.
In short, the argument for eliminating fixnums seems to be based on an
overemphasis on one aspect of portability rather than a consideration
of what programmers actually do and want.
> > From: Jeff Dalton <jeff%aiva.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
> > Date: Mon, 11 Jul 88 21:32:31 bst
> >
> > Even though fixnums may differ from implementation to
> > implementation, I want a standard way to use them when they exist
> > rather than allow implementations to diverge (so that some call
> > them fixnums, others something else, and so on).
>
> Having a standard name is of little use unless it is tied to some
> standard semantics. The problem is that there is no guarantee what
> you get when you say "fixnum". There is currently no absolute
> prohibition against defining the range of fixnums to be something
> like 100,000 to 100,010.
Well, then perhaps int and long in C are of "little use". They are
not guaranteed to be the same size everywhere.
Note too that your argument is for reforming fixnums, not for
eliminating them, and I am not arguing against reform.
> If you want "small integer", then by all means define your own small
> integer type using DEFTYPE. That way you're guaranteed to have it
> mean exactly the same thing in all implementations.
You may want it to mean "exactly the same thing" (meaning exactly the
same size); that is not what I am asking for.
Besides I don't want a small integer, I want an efficient one. A
subrange is not guaranteed to be efficient, and so does not replace
FIXNUM.
> > I do not accept the argument that it doesn't matter because everyone who
> > provides fixnums can still provide them. If they're not in the standard,
> > users cannot in fact rely on them being provided in a standard way.
Note that your response about packages below does not answer this.
> > Indeed, if we decide to allow only standard symbols in the LISP package,
> > users would have to type LUCID:FIXNUM, EXCL:FIXNUM, etc. rather than just
> > FIXNUM as they can now.
> Why not just import the appropriate symbol into the package you're using
> once, and be done with it?
This is still not providing fixnums in a standard way. I still have
to add some conditional code for each implementation.
> > Date: Tue, 12 Jul 88 10:33:24 BST
> > From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
> If your implementation supports a range of small integers
> that are more efficient than larger integers, there is already a portable
> way to declare them as such.
The range gets ported, but the efficiency may not. Fixnums work
adequately over a wide range of implementations without requiring
implementation-specific customization of my types. I am even willing to
have some programs not work in implementations that have a sufficiently
losing notion of fixnums, just as I am willing to do this in other
langauges.
> To draw an analogy, small bignums are likely to be considerably faster and
> more efficient than large bignums. Should we assign a special name to
> bignums with less than N "bigits" simply because they're faster than bignums
> that are larger than that?
That we do not want a name for every class of more efficient number
does not show we do not want a name for any such class.
Moreover, compilers can (or at least do) get more in the way of
optimization from fixnums than they would from "small bignums".
> It appears I was misinformed on this point -- I was under the impression
> that KCL boxed all integers and simply preallocated a range of small
> integers.
It does "box" all integers (though fixnum declarations may avoid this in
compiled code). But the representation of fixnums is simpler than
that for bignums. It is very much like Franz in this respect.
-- Jeff
∂18-Jul-88 1555 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88 15:54:37 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06386; 18 Jul 88 21:20 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa27619;
18 Jul 88 21:45 BST
To: sandra <@cs.utah.edu:sandra@cdr>
CC: cl-cleanup@sail.stanford.edu, KMP@scrc-stony-brook.arpa,
jeff <@NSS.Cs.Ucl.AC.UK:jeff@aiva.edinburgh.ac.uk>,
jpff <@NSS.Cs.Ucl.AC.UK:jpff@maths.bath.ac.uk>
In-reply-to: sandra (Sandra J Loosemore)'s message of Tue, 12 Jul 88 09:08:25 MDT <8807121508.AA23357@cdr.utah.edu>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Mon, 18 Jul 88 21:44:49 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>>To draw an analogy, small bignums are likely to be considerably faster and
>>more efficient than large bignums. Should we assign a special name to
>>bignums with less than N "bigits" simply because they're faster than bignums
>>that are larger than that? How useful would having such a special name be
>>when both N and the size of the "bigit" vary from implementation to
>>implementation?
But the factors are much much bigger. I still am not conmvinced by
your arguments for getting rid of FIXNUMS. Maybe they should be
better defined, but I cannot see a portable way of getting the effect
I get in FORTRAN, C, etc etc
==John
∂18-Jul-88 1556 CL-Cleanup-mailer issue BOGUS-FIXNUMS (initial draft)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Jul 88 15:56:28 PDT
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07064; 18 Jul 88 23:11 BST
Received: from xenakis by mordell.maths.bath.AC.UK id aa28020;
18 Jul 88 23:36 BST
To: KMP@scrc-stony-brook.arpa
CC: sandra <@cs.utah.edu:sandra@cdr>, CL-Cleanup@sail.stanford.edu
In-reply-to: Kent M Pitman's message of Mon, 18 Jul 88 17:31 EDT <880718173159.5.KMP@PEWEE.SCRC.Symbolics.COM>
Subject: issue BOGUS-FIXNUMS (initial draft)
Date: Mon, 18 Jul 88 23:36:04 BST
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
>> The problem I have with being told I should DEFTYPE my own SMALL-INTEGER is the
>> following:
That is well put; I think that is what I was trying to say. Thank
you.
==John
∂18-Jul-88 1957 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Jul 88 19:57:11 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 18 Jul 88 22:56:05 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Mon, 18 Jul 88 17:02:00 -0400.
<880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Mon, 18 Jul 88 22:55:49 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Can you elaborate on the kind of ``confusion and paralysis of truly
awsome proportions'' you expect?
Sure. I expect to see several hundred spurious bug reports of the form "I
told Lisp to replace the extension of this file with `foo' and for some
unknown reason it insisted on producing `filename.FOO'. That's the form
the spurious report would take for people on lower-case systems like Unix
-- others would have a slightly different problem.
I agree that it would be nice if everyone read the manual, but if a feature
of the language is sufficiently non-intuitive, people are going to be
burned even if there's a warning in red letters -- they'll just refuse to
believe that the language designers could have been so perverse. Suppose
we decided that it would be useful to represent positive integers as "-n"
and negative integers as "+n". Do you think that documenting this decision
would turn it into good language design? I think not, but you are
proposing to tell Unix-based users, and lots of others, that for them "FOO"
means you want lower case in the filename and "foo" means you want upper
case.
As you point out, this would an effectively incompatible change in a part
of the language that is used moderately heavily, though usually for rather
simple tasks. A lot of users regard most of the pathname stuff as bizarre
nonsense that they really don't want to understand, but they have learned
to do a few simple things (e.g. moving files between directories and
changing file extensions) by rote. Only a few sophisticated users are
concerned with writing code that works across many systems with radically
different file-naming conventions. If we can give these sophisticated
users a better way in which to do their job, fine, but I don't think we
should accomplish this by screwing the people who have existing code that
solves their little file problems within, say, an all-Unix environment and
who never plan to export their code to Tenex. (I hope you aren't going to
reply that such people deserve to be screwed, since they should not be
writing nasty non-portable code.)
Can you also give a couple examples of what you consider portable
uses of the current paradigm which do not involve the use of READ-LINE
in order to obtain a namestring in the first place?
No. I think that the existing pathname stuff is pretty much a dead loss
for this purpose due to the problem you describe and several others. If it
were up to me, we'd toss this pathname mess out and start over, but it's
too late for that. If we can patch over the worst of these problems, fine,
that's useful. I'm not arguing with your goals. I just don't think we
have to do this in a way that breaks existing code and that will stand
forever as a textbook example of counter-intuitive language design.
Aside from my distaste for a system in which "foo" means "FOO" and
vice-versa, I do have one technical objection to your proposal: unless I've
missed something, there's no way to specify that you want some string to be
used verbatim, regardless of the target system, unless that string happens
to be of mixed case. I guess in unix the "canonical" case is lower, but
sometimes you want to specify a file whose name is something like
"foo.BAR". So if we overload the field-value strings to signal
case-canonicalization, we need some way to quote these strings and say
"this is really what I want, so leave it alone".
Would it suffice to add a :CANONICALIZE-CASE keyword to MAKE-PATHNAME for
those few users who really are trying to write code that will run on all
known systems? That would be an upward compatible change. If we need
field-by-field control of case-canonicalization, I think that the
CANONICALIZE-CASE function I proposed earlier does the job quite well, even
if it is a bit verbose. I'd rather have a form that states that this
canonicalization is going on than to surprise naive users by doing it when
they are not expecting it. Alternatively we could try to work out the
syntax for a new function or macro, MAKE-PORTABLE-PATHNAME, that
accompanies each field specifier with a flag of some sort indicating how
the case is to be treated.
The pathname
system from which I took the idea for this proposal is one of very few I
know of which has tried this approach and demonstrated it to be workable in
the face of numerous operating systems. Frankly, the only comments I've ever
heard numerous users of the Symbolics pathname system were ones of astonishment
at how well that aspect of the lisp machine pathname system works. So it
seems to me that the facts are in direct opposition to your ``doom and gloom''
prediction. Do you contest this claim or practical experience to the contrary
which you would like to share?
No, I'm just flaming, based on instrospection and my rough model of how
naive users are likely to think; I haven't run any experiments. If you
tell me that Symbolics already uses the system that you propose and that
the users are unanimous in their praise of it, I guess I'll have to accept
that, surprising as it may be. I know that I personally would find it
confusing to write "foo" when I mean "FOO" and vice versa, but then I've
always been kind of slow at catching onto these advanced programming
concepts. Maybe I'm the only one with this hangup, or maybe I'm typical
and the Symbolics user community has learned not to complain about things
that seem overly complex and counter-intuitive.
Some other views would be useful at this point. If the rest of you think
that KMP's proposed change is the most intutive way to handle this case
problem, I'll shut up -- I no longer have formal voting rights in any case.
-- Scott
∂18-Jul-88 2033 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Jul 88 20:33:18 PDT
Received: from Burger.ms by ArpaGateway.ms ; 18 JUL 88 20:31:59 PDT
From: masinter.pa@Xerox.COM
Date: 18 Jul 88 20:31:02 PDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Mon, 18 Jul 88 22:55:49
EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880718-203159-4394@Xerox>
My general goal is to try to standardize current practice, and reduce needless
divergence. As far as I can tell, there are lots of both case sensitive and case
insensitive file systems around. We might be lucky if we can
a) standardize how pathnames work when talking to various kinds of operating
systems (e.g., all Unix Common Lisps should use file names the same way) and
b) give users some guidelines on how to write portable code given that there are
inevitable differences.
Certainly a proposal that mandates an "unnatural" interface between Lisp and the
host operating system will be rejected by the operating system vendors.
∂19-Jul-88 0805 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88 08:05:43 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435112; Tue 19-Jul-88 11:04:36 EDT
Date: Tue, 19 Jul 88 11:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: masinter.pa@Xerox.COM, Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880718-203159-4394@Xerox>,
The message of 18 Jul 88 22:55 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880719110427.6.KMP@PEWEE.SCRC.Symbolics.COM>
Date: 18 Jul 88 20:31:02 PDT
From: masinter.pa@Xerox.COM
My general goal is to try to standardize current practice, and reduce needless
divergence. As far as I can tell, there are lots of both case sensitive and case
insensitive file systems around. We might be lucky if we can
a) standardize how pathnames work when talking to various kinds of operating
systems (e.g., all Unix Common Lisps should use file names the same way) and
b) give users some guidelines on how to write portable code given that there are
inevitable differences.
Speaking now with my user's hat on, I must say that I think this is a
complete whimp-out.
The plain fact is that programmers need MUCH more than a&b, and we are capable
of providing it. Current practice is that there are at least some implementations
which deal exceedingly well with a lot of kinds of operating systems in the
same environment. If we cannot select and standardize on one of those models, it
seems clear to me that the reasons are political and not technical.
Certainly a proposal that mandates an "unnatural" interface between Lisp and the
host operating system will be rejected by the operating system vendors.
I can't tell if this remark about unnaturalness alludes to my proposal,
but I'll assume it does and reply on that premise...
I don't intend to propose an "unnatural" interface between Lisp and the
host operating system. In fact, I don't see the functions I'm proposing changing
as part of the interface between Lisp and the operating system. I see them as
an interface to an abstract operating system.
The purpose of the pathname system seems to me to have been to abstract away
from operating systems a bit and provide a portable file system model which
was device independent.
For example, we typically parse out `type' information where there
really is none on Unix. That idea is in some sense unnatural to Unix, but it
is not unnatural to the idea of a file system, and CL programmers thought it
would be useful. So we created a model and users seem happy with it because
it provides them something of value.
Issues of case are completely non-trivial to writers of portable code. The
proposed solution does not intend to slight any host operating system. The
idea is to say that there is a partition in the file system interface:
A pathname is an abstract representation of a filename. It contains
information in its slots which ties it to a particular host file system,
but it is designed in such a way that it can be manipulated with minimum
regard for the particular characteristics of the host operating system.
The MAKE-PATHNAME operation creates pathnames.
PATHNAME-HOST, PATHNAME-DEVICE, etc. access the abstract representation.
A namestring is a concrete representation of a filename. Since
namestrings are not portable, a namestring is rarely part of a program
and is more commonly the result of user typein or of an operation such
as NAMESTRING which coerces a pathname to its native string
representation.
An Idea
In some ways this smells of the FIXNUM issue. Perhaps the problem is
partly just that you have interesting functionality that you don't want
to lose and I can talk you into just `saying what you mean.' Currently
there are two arguably desirable pieces of functionality, and only one
name. Maybe if there were two names, we could make one name refer to what
Scott wants and one name refer to what I want.
In Genera, you can do (SEND pathname :RAW-NAME), etc. to see the
host-specific values, but hardly anyone ever does this in any code I've
ever seen. I would be willing to extend the proposal in any of the
following ways if it would make it more palatable to anyone:
(a) Add functions PATHNAME-RAW-DEVICE, PATHNAME-RAW-DIRECTORY,
PATHNAME-RAW-NAME, PATHNAME-RAW-TYPE, PATHNAME-RAW-VERSION.
[We could use "NATIVE" instead of "RAW" if people found that more
appealing. It is longer, though.]
(b) Add an optional NATIVE-P argument which controlled case translation
and such in the PATHNAME-xxx accessors. For the sake of portability,
I would definitely want this argument to default to NIL (meaning that
the default was to return a canonicalized value, but that it could
be overridden to inhibit this behavior by people that wanted it).
There are also a couple of interesting variants of (a) which we could
even play with:
(a1) Make functions FILENAME-HOST, FILENAME-DEVICE, etc. which were like
PATHNAME-HOST, etc. except:
- They would accept any argument that was coerceable to a
pathname.
- They would return the argument in native form.
eg, (FILENAME-NAME "/foo/bar.lisp") => "bar" on Unix
(a2) Extend the set of functions like FILE-NAMESTRING to include
NAME-NAMESTRING, TYPE-NAMESTRING, and VERSION-NAMESTRING so that
it would be more easily possible to pick apart namestrings.
These latter two, especially a1, have the version of making the -raw-
things feel perhaps less like second-class citizens. [Personally, I don't
really care if they are second-class citizens because in my view they
really are. CL is supposed to be a portable language, and I'm content to
provide non-portable features only to the extent that it doesn't get in
the way of providing portable ones. In this case, the names PATHNAME-NAME,
etc. have a right (I feel) to the portable semantics. As long as we don't
muck with that, I'm content to provide whatever else is necessary to
make others happy.]
Aside to Fahlman: I don't think voting rights have much to do with
anything in this forum, so I wouldn't worry about that. I'm happy to
hear your opinion when you're willing (as you were) to elaborate on
your fears enough that we can have a technical discussion.
∂19-Jul-88 0823 CL-Cleanup-mailer EQUAL, and hash tables, and value/object distinctions
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88 08:23:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435123; Tue 19-Jul-88 11:23:14 EDT
Date: Tue, 19 Jul 88 11:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: EQUAL, and hash tables, and value/object distinctions
To: Jon L White <edsel!jonl@labrea.stanford.edu>
cc: Greenwald@STONY-BROOK.SCRC.Symbolics.COM, jrose@sun.com, goldman@vaxa.isi.edu,
common-lisp@SAIL.STANFORD.EDU
In-Reply-To: <8807190705.AA05728@bhopal.lucid.com>
Message-ID: <19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
bcc: CL-Cleanup@SAIL.STANFORD.EDU
Date: Tue, 19 Jul 88 00:05:31 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
....numerical equality and inequalities are not
information losing, and should in fact be transitive relations. About
one year ago, I pointed out this difficulty to Guy Steele with some well-
chosen examples; and he was quite shocked -- indeed it was his intention
that "=" be a true equivalence predicate.
I agree that = should be transitive even when floating-point numbers are
involved. I.e. (= (/ 10.0 single-float-epsilon)
(1+ (floor (/ 10.0 single-float-epsilon))))
should be NIL, since
(= (/ 10.0 single-float-epsilon)
(floor (/ 10.0 single-float-epsilon)))
is certainly T and
(= (floor (/ 10.0 single-float-epsilon))
(1+ (floor (/ 10.0 single-float-epsilon))))
is certainly NIL. To understand this example better, it helps
to realize that (= (/ 10.0 single-float-epsilon)
(+ (/ 10.0 single-float-epsilon) 1.0))
is true in all implementations.
Since CLtL p.194 expressly forbids this, requiring the first form above
to return T, shouldn't somebody submit an X3J13 Cleanup subcommittee
proposal before it's too late?
Lucid's 3.0 release performs "appropriate contagion" in the case of
numerical comparisons, in order to preserve transitivity.
I'm a little surprised that Lucid would change their implementation
incompatibly with both CLtL and previous Lucid implementations without
first getting some concensus that the current definition of Common Lisp
is wrong and in fact will change. I know Symbolics specifically decided
not to "fix this bug" unilaterally when we noticed it some time ago,
considering that compatibility was more important. Chacun a son gout.
∂19-Jul-88 1342 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jul 88 13:42:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA27114; Tue, 19 Jul 88 14:41:47 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA00292; Tue, 19 Jul 88 14:41:39 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807192041.AA00292@cdr.utah.edu>
Date: Tue, 19 Jul 88 14:41:32 MDT
Subject: SUBTYPEP-TOO-VAGUE, version 2
To: cl-cleanup@sail.stanford.edu
Here is a revised version of SUBTYPEP-TOO-VAGUE. I changed the status
of the MEMBER type specifier and added a requirement that EQUAL type
specifiers be recognized as equivalent.
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, MEMBER,
NOT, AND, OR, the list form of FUNCTION, or VALUES type specifiers.
(2) If a type specifier defined with DEFTYPE is passed to SUBTYPEP,
SUBTYPEP must treat it in the same way as if its expansion were passed
instead.
(3) SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
(4) Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with. I don't know how one
would compare FUNCTION or VALUES type specifiers; some rules could be
established to clarify how to compare them but I don't think it would
would be particularly useful to do so.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
None.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
Item (4) appeared to be the consensus from a discussion on the
common-lisp mailing list some time ago.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
-------
∂19-Jul-88 1350 CL-Cleanup-mailer more on BOGUS-FIXNUMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Jul 88 13:49:52 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA27381; Tue, 19 Jul 88 14:49:30 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA00305; Tue, 19 Jul 88 14:49:26 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807192049.AA00305@cdr.utah.edu>
Date: Tue, 19 Jul 88 14:49:19 MDT
Subject: more on BOGUS-FIXNUMS
To: cl-cleanup@sail.stanford.edu
Apologies if this is a repeat -- I sent this message out a few days
ago but it seems to have dropped into the bit bucket. I'm willing to
write up a new proposal on this issue, but I'm not sure what direction
the committee wants it to go in.
----
Since it appears that nobody besides me (and Stan) likes my previous
proposal on this issue and that I'll have to come up with something
less radical that is more acceptable to the rest of the committee, I
thought it would be useful to enumerate some of the possibilities. I
realize there are still two other issues which would still have to be
addressed when turning any of these into a real proposal, namely
whether to retain MOST-BLETCHEROUS-FIXNUM :-), and whether the BIGNUM
type specifier should remain and whether it must still be a non-empty
set which is disjoint from FIXNUM.
#0 (what CLtL says):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined but nothing is said about its
range.
- FIXNUMs are required to have a more efficient representation than
non-FIXNUMs.
#1 (my original proposal):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier goes away.
- user-defined integer subrange types use the most efficient
representation possible in a given implementation.
#2 (Gail Zacharias's counter-proposal):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined to be a superset of
(SIGNED-BYTE n), for some value of "n" which has yet to be
decided but that we all agree upon.
- FIXNUMs are not required to coincide with or be a subset of the
set of integers which are represented most efficiently.
#3 (change CLtL's "typically" to a firm requirement):
- there is no particular type specifier defined for "small integers".
- FIXNUMs must be a supertype of (SIGNED-BYTE n).
- FIXNUMs are defined to be the set of integers which are represented
most efficiently.
#4 (dumb, but here for completeness):
- there is no particular type specifier defined for "small integers".
- the FIXNUM type specifier is defined to be equivalent to
(SIGNED-BYTE n).
- FIXNUMs are required to be a subset of the integers which are
represented most efficiently.
#5: (Kent Pitman's suggestion):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the FIXNUM type specifier goes away.
- nothing is guaranteed about the efficiency of representation of
SMALL-INTEGERs.
#6 (similar to #3):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the set of FIXNUMs is required to be a superset of SMALL-INTEGERs.
- FIXNUMs are defined as the set of integers with the most efficient
representation. (This implies that SMALL-INTEGERS are also
guaranteed to be efficient.)
#7 (a cross between #0 and #5):
- a new SMALL-INTEGER type specifier is introduced which is equivalent
to (SIGNED-BYTE n).
- the FIXNUM type specifier remains but the range of FIXNUMs is left
undefined, as is the relationship between FIXNUM and SMALL-INTEGER.
- FIXNUMs are defined as the set of integers with the most efficient
representation. Nothing is guaranteed about the efficiency of
SMALL-INTEGERs.
Comments, anyone?
-Sandra
-------
∂19-Jul-88 1453 CL-Cleanup-mailer more on BOGUS-FIXNUMS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Jul 88 14:53:08 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 435456; Tue 19-Jul-88 17:52:04 EDT
Date: Tue, 19 Jul 88 17:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: more on BOGUS-FIXNUMS
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807192049.AA00305@cdr.utah.edu>
Message-ID: <880719175155.9.KMP@PEWEE.SCRC.Symbolics.COM>
I'd like to see a full blown proposal based around #7.
∂20-Jul-88 1147 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Jul 88 11:44:38 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06730; 20 Jul 88 19:18 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 20 Jul 88 19:13:13 BST
Message-Id: <8514.8807201813@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, Scott.Fahlman@b.gp.cs.cmu.edu,
masinter.pa@xerox.com
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Cc: CL-Cleanup@sail.stanford.edu
> Date: Tue, 19 Jul 88 11:04 EDT
> From: Kent M Pitman <KMP@arpa.scrc-stony-brook>
> A namestring is a concrete representation of a filename. Since
> namestrings are not portable, a namestring is rarely part of a program
> and is more commonly the result of user typein or of an operation such
> as NAMESTRING which coerces a pathname to its native string
> representation.
I guess I don't understand this point, because I don't see that pathnames
are all that portable. Aren't the files usually in a different place on
different machines, and so musn't the pathname be different for different
machines? A pathname might work if I'm creating a file and am willing to
have it go to some default place (the current directory, say), but
otherwise I may have to know there's a place called "/tmp" or something
of that sort.
Moreover, it turns out that many programs do contain namestrings. The
defsys in PCL is one example. They are immediately converted to pathnames,
but nonetheless start out as namestrings.
-- Jeff
∂20-Jul-88 1217 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Jul 88 12:17:00 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06991; 20 Jul 88 20:01 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Wed, 20 Jul 88 19:55:54 BST
Message-Id: <8564.8807201855@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu
> Date: Tue, 19 Jul 88 17:51 EDT
> From: Kent M Pitman <KMP@arpa.scrc-stony-brook>
> I'd like to see a full blown proposal based around #7.
It might be interesting to see one, but #7 has small-integers, which have
at least a certain size but may be inefficient, and fixnums, which are
efficient (if anything is) but may have (or not have) any size. I am not
sure why anyone would want to use these small integers rather than specify
exactly what range/size they want. Are we supposed to imagine they might
very well be efficient just as fixnums might very well be a reasonable
size? The only definite advantage to small integers is that they're
portable, but they're portable in a sense I'm not sure anyone cares about.
A definite disadvantage, however, is to create confusion between fixnums
and small integers, and also confusion between these small integers and
what some Lisps have called small integers, namely the ones represented
"directly by pointers".
∂20-Jul-88 1535 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Jul 88 15:35:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436177; Wed 20-Jul-88 18:33:07 EDT
Date: Wed, 20 Jul 88 18:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
masinter.pa@Xerox.COM, Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8514.8807201813@subnode.aiai.ed.ac.uk>,
<880719110427.6.KMP@PEWEE.SCRC.Symbolics.COM>,
<880718-203159-4394@Xerox>,
The message of 18 Jul 88 22:55 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
<880718170217.3.KMP@PEWEE.SCRC.Symbolics.COM>,
The message of 18 Jul 88 16:42 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
<880701195711.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880720223239.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I support the proposal (PATHNAME-COMPONENT-CASE:CANONICALIZE). I think
current practice in the Symbolics Genera system (and I believe in the TI
Explorer system as well) has shown that this approach is very viable for
dealing portably with a wide range of file systems. The choice of upper
rather than lower case as the canonical case is of course arbitrary; a
justification of upper case is for consistency with Common Lisp symbols.
I agree with Kent that if this situation is not straightened out, pathnames
are not very useful for portable programs, and that straightening out the
situation will be a big help in that respect.
I would also support a variant of this proposal that augmented the
portable pathname constructor and accessors with a native constructor
and accessors, either with different names or as additional arguments to
the same-named functions. I assume Kent left the native constructor and
accessors out of his original proposal because he wanted to keep it lean
and omit unnecessary complications. However, if Scott feels they should
be included, I'm happy to let them be included. I agree with Kent that
in practice the portable operations are used much more commonly than the
native operations. I believe this is because programs that work in
terms of native pathnames typically use namestrings and do not access
pathname components at all.
Date: Wed, 20 Jul 88 19:13:13 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
I guess I don't understand this point, because I don't see that pathnames
are all that portable. Aren't the files usually in a different place on
different machines....
I have to comment on this, because it's a common misconception.
Actually there are two points that have to be made. First, we are not
talking about making pathnames portable, we are talking about making
pathname-manipulating programs portable. That's a big difference! The
point is to provide portable ways to perform the operations whose
details vary across file systems. In fact that is the -only- point of
pathnames; if we didn't want to do that, we would just use strings and
manipulate them with string operations. The pathname abstraction was
introduced solely to make pathname-manipulating programs portable.
The second comment is that it is in fact both possible and useful to make
pathnames themselves portable. That would be the subject of a separate
proposal. Again, this has been current practice in both Symbolics and TI
systems since before Common Lisp even existed, and works quite well. The
interested reader can consult the documentation of "logical pathnames"
for either of those systems. Basically the idea is to have an imaginary
file system that behaves in the same way everywhere, and that puts files
in the same place everywhere. Then at each location one defines a set of
translations that implement the imaginary file system by mapping it into
a real file system. Any namestring embedded in a program ought to be
a logical namestring if one expects that program to be at all portable.
∂20-Jul-88 1712 CL-Cleanup-mailer re: encourage no side-effect garbage
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88 17:11:58 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA01259; Wed, 20 Jul 88 17:09:09 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA17562; Wed, 20 Jul 88 15:48:35 PDT
Date: Wed, 20 Jul 88 15:48:35 PDT
Message-Id: <8807202248.AA17562@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: re: encourage no side-effect garbage
My last comment in my proposal should be amended to say that what I
find distasteful is storage allocated in executing a Common Lisp
function that not returned to me as part of the return value AND
becomes garbage immediately upon return of the function. Obviously
Lisp maintains internal state that includes allocated storage not
available to the user; this is not the object of my "distaste".
∂20-Jul-88 1732 CL-Cleanup-mailer proposal: encourage no side-effect garbage
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88 17:32:42 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA09177; Wed, 20 Jul 88 15:30:24 PDT
From: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Received: by trwrb.TRW.COM (5.51/1.36)
id AA15969; Wed, 20 Jul 88 15:00:40 PDT
Date: Wed, 20 Jul 88 15:00:40 PDT
Message-Id: <8807202200.AA15969@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: proposal: encourage no side-effect garbage
Issue: ENCOURAGE NO SIDE-EFFECT GARBAGE
References: CLtL
Category: ADDITION
Edit history: Version 1, 20-Jul-88, Ginder
Problem description:
Many Common Lisp implementation create garbage as a side effect of
executing standard Common Lisp functions. Under some circumstances,
this renders an Common Lisp "primitive" provided according to CLtL
unusable by applications under serious performance requirements or
virtual or physical memory space limitations.
Proposal:
Strongly encourage (not require) Common Lisp implementations to manage
internally-allocated storage in a manner so as not to generate garbage.
Explicitly point out that the quality of a Common Lisp implementation is
directly related to how well it solves this problem.
Rationale:
Some Common Lisp programmers need to write programs that react in
real-time to monitor physical processes or react to crisis situations.
It is imperative that some programs not be interrupted by a GC nor grow
so large by deferring GC that performance degrades. It should be
possible to write programs with static memory requirements in Common
Lisp.
Current practice:
Programmers replace Common Lisp functions with private versions that
do not create garbage as necessary.
Cost to Users:
No cost, this is upward compatible. (Users may get to throw away some
code, though!)
Cost of non-adoption:
Those programmers needing to avoid garbage creation can't or must
re-write parts of Common Lisp.
Benefits:
Unnecessary GC's will be avoided. Common Lisp programs will work in a
more predictable manner. Side-effect generation of garbage by an
implementation will become a more visible criterion for judging the
quality of an implementation.
Esthetics:
Neutral to vastly improved, depending on your orientation. It is
extremely distasteful to me for a Common Lisp function to allocate more
storage than it returns to me as a value.
--Joe Ginder, Inference
∂20-Jul-88 1751 CL-Cleanup-mailer proposal: eliminate forced consing
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 20 Jul 88 17:51:41 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA09616; Wed, 20 Jul 88 15:56:24 PDT
From: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Received: by trwrb.TRW.COM (5.51/1.36)
id AA15976; Wed, 20 Jul 88 15:00:44 PDT
Date: Wed, 20 Jul 88 15:00:44 PDT
Message-Id: <8807202200.AA15976@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: proposal: eliminate forced consing
Issue: ELIMINATE FORCED CONSING
References: CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2
Category: ADDITION
Edit history: Version 1, 20-Jul-88, Ginder
Problem description:
The sequence functions included in CLtL encourage a programming style
that causes excessive storage allocation compared to libraries of
routines with similar functionality in other languages, notably C.
The only options available to the Common Lisp programmer who uses
these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function.
Proposal:
Add a :TARGET keyword argument to those sequence functions where such an
argument is useful, as specified below, which allows passing a target
argument sequence into which the result of the sequence computation is
to be placed. The sequence function returns the target sequence
modified as specified below:
(1) The target sequence must accomodate elements of the type(s)
in the source sequence. Thus it would be an error to give a
target string argument if the source sequence had elements that
were not of type STRING-CHAR.
(2a) A non-list target sequence should have an allocated length
long enough to accomodate the normal result of the sequence
function. It is permissable for the target sequence to have a
fill pointer; in this case, the fill pointer is set to point
immediately after the last element filled in by the sequence
computation. If the target sequence is longer than necessary,
the unneeded trailing elements are unchanged.
(2b) A list target sequence argument is extended with new conses
to be as long as necessary to accomodate the resulting sequence,
if not enough conses are supplied and the :TARGET-FROM-END keyword
is nil. The tail of the target list sequence not used to
accomodate the sequence computation is returned as a second
value by the sequence function, but remains linked as the tail
of the target sequence. [It might be desirable to return a
third value, the last cons of the part of the list used for
the result sequence, permitting the programmer to null-terminate
that part of the target sequence, breaking the link with the
unused tail, if appropriate.]
(3) A :TARGET-FROM-END keyword is supported. If non-nil, the
target sequence is filled with new elements starting at the
end of the target seqeunce, effectively reversing the order of
elements of the resulting sequence in the target. In this case,
an error is signalled if the target sequence is not long enough
for the result. If the target sequence is longer than necessary,
leading elements are unchanged.
(4) :TARGET-START and :TARGET-END keywords are supported.
TARGET-START and TARGET-END determine where in the target
sequence the result of the sequence computation is placed.
An error is signalled if the sub-length of the target
sequence specified by these arguments is not long enough to
accomodate the resulting sequence computation. If a longer
than necessary sub-length is specified, then the elements in
the unneeded part of the specified sub-length are unchanged.
Affected sequence functions:
subseq, copy-seq, reverse, remove, remove-if, remove-if-not,
remove-duplicates, substitute, substitute-if, substitute-if-not,
merge
Affected list functions:
copy-list, butlast
copy-alist, copy-tree, adjoin, union, intersection, set-difference,
set-exclusive-or
[no TARGET-START/END or TARGET-FROM-END, just destructive
use of the :TARGET conses]
Affected string functions:
string-trim, string-left-trim, string-right-trim, string-upcase,
string-downcase, string-capitalize
Examples:
(copy-seq '(1 2 3) :target '(a b c d e f g))
=> (1 2 3 d e f g)
(copy-seq '(1 2 3) :target '(a b c d e f g) :target-from-end t :end 5)
=> (a b 3 2 1 f g)
(remove 'a '(b b a b b a b b a b b) :count 1 :target '(3))
=> (b b b b a b b a b b) ; EQ to :TARGET arg, CDR is new conses.
;;; Note, the :TARGET arg has a fill pointer.
(substitute #\a #\b "This is a string with 2 a's"
:target "0123456789012345678901234567890123456")
=> "This is b string with 2 b's"
In a related addition, provide extended versions of concatenate, append,
revappend, and make-string-output-stream as follows:
concatenate-into target &rest sequences
Like CONCATENATE, but the result type is determined to be
the type of TARGET. The result is TARGET containing as many
of the elements of SEQUENCES as can be accomodated by the
allocated length of TARGET. TARGET's fill pointer, if
present is set according to how many elements of TARGET ar
filled by this operation.
concatenate-into-subseq target start end &rest sequences
Like concatenate-into, but copied from SEQUENCES into the
sub-sequence of TARGET specified by START and END.
append-into target &rest lists
Like APPEND, but the copied list arguments are copied into
conses taken from TARGET. The last list in LISTS
is not copied, as in APPEND, rather, the last cons used
from TARGET is given the last list in LISTS as its cdr.
The result is EQ to TARGET (unless a single list is appended),
but contains only those conses needed to hold the appended
lists' elements. The tail of unused conses from TARGET is
returned as a second value; new conses are allocated if
TARGET supplies an insufficient number of conses.
revappend-into target x y
Like REVAPPEND, but the new conses are taken from TARGET.
The result is EQ to TARGET, but contains only those conses
needed to hold X's elements. The tail of unused conses
from TARGET is returned as a second value; new conses are
allocated if TARGET supplies an insufficient number of conses.
make-string-output-stream &optional string
Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
is provided, make the string-stream write to it rather than
a newly-allocated string. An error is signalled if the output
overflows the supplied string.
A related optimization that compilers should be encouraged to support
is to recognize:
(concatenate 'string (subseq ...) (subseq ...) (subseq ...) ...)
as being optimizable so as to avoid the allocation of storage for
intermediate SUBSEQ results. This is a very common programming idiom
that can, of course, be expressed using the proposed extensions to avoid
intermediate consing. However, the extensions do not provide as concise
and readable a mechanism for re-espressing this idiom as may others.
Other extensions might be considered to address this:
(1) Provide a CONCATENATE function that takes a &rest
argument of sequence/start/end triples.
(2) Provide a special form like:
(designate-subseq sequence start end)
that didn't actually allocate anything but provided an imple-
mentation-specific "handle" on the subsequence for use
in such expressions as the CONCATENATE expression above.
(They'd print as the subseq, and setf's of their elements
would destructively modify the original sequence.)
However, there is no precedent in CLtL for (1). And (2) seems like a
complex, sweeping change (for implementors) of limited benefit somewhat
in conflict (though more general than) displaced arrays. So I don't
want to propose either.
Rationale:
It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Excessive storage allocation is one of Lisp's most widely publicized and
least understood faults.
Current practice:
Similar functionality is provided for bit-vectors, as specified in CLtL
17.4. A related capability is provided in the destructive versions of
some of the functions extended above.
When functionality similar to this is required, users must "roll their
own". My experience in several commercial Lisp applications is that
avoiding storage allocation by using programming techniques such as this
may be critical to the success of a project. The current sequence,
list, and string functions encourage an "expensive", albeit easier to
use, programming style that invites the creation of programs whose
performance suffers greatly in comparison to a program written to solve
the same problem written in C.
Cost to Implementors:
The cost of implementation of these extra sequence function arguments is
significant, but would not be burdensome compared to the utility
provided. (In my humble opinion, of course.)
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
I submit that the cost of NOT implementing this sort of functionality is
that Common Lisp deserves the reputation it is rapidly gaining of being
very expensive to use, not in programmer productivity, but in the
resources required by the resulting programs. While it is certainly
easier to write programs that always allocate new storage for results,
it is very expensive compared to what average programmers write in other
languages. Sometimes the correct trade-off is to invest the extra
programming effort in development of a product in exchange for the
lowered resource requirements in the delivered system. This is
particularly true when the deployed Lisp application may have thousands
of instances. It may well be worth several extra man-years of effort to
use facilities such as those mentioned above rather than pay the
increased cost of deployment thousands of times! (These costs are in
the form of more expensive hardware for deployment. This might be due
to higher memory requirements or larger disk space requirements to
support a large virtual memory image.) If Common Lisp does not provide
this capability; programmers under serious performance constraints will
choose a different tool.
Benefits:
Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement. Programmers
learning Common Lisp will be challenged to understand the difference
between allocating new storage and re-using old storage as they
understand why these arguments are supported. This is one of the chief
problems that most programmers encounter as they write Lisp programs.
I've encountered MANY occurances of this problem in helping people who
are trying to write Lisp programs as part of a real-world application
that is intended to be delivered on hardware for which someone must pay
real $$. The problem encountered is that the program is too slow, or
requires hardware too expensive for practical deployment. The most
common result is that the programmer gives up, proclaiming that Lisp is
too slow or too resource intensive, and rewrites his program in C.
Although these enhancements alone are not sufficient to solve the cited
problem, something along these lines is necessary as part of a more
complete solution that might include better training of Lisp
programmers, stack consing, and ephemeral GC. The real benefit of
adopting this extension to sequence functions and similar extensions is
an increased chance of survival for Lisp as a viable tool for creating
deliverable applications.
Esthetics:
This proposal is likely to cause flames from the "functional
programming" camp (unless they've all left for Scheme). It is
consistent (syntactically) with the existing keyword arguments to
sequence functions. It adds to the plethora of keyword arguments already
present for many of these functions.
Discussion:
I'd likely tolerate any sort of statements in the new CL manual warning
naive users of the dangers of this programming style. I agree that it
can be mis-used; but sometimes the benefit is worth the risk. I simply
want Common Lisp to provide the choice.
Would adoption of these arguments eliminate the need for parallel
destructive versions for some of the affected functions? (E.g., does
REMOVE with a :TARGET argument eliminate the need for DELETE.)
--Joe Ginder, Inference
∂21-Jul-88 0622 CL-Cleanup-mailer Re: proposal: encourage no side-effect garbage
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88 06:22:28 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Jul 88 22:59:15 EDT
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
Subject: Re: proposal: encourage no side-effect garbage
In-reply-to: Your message of Wed, 20 Jul 88 15:00:40 -0700.
<8807202200.AA15969@trwrb.TRW.COM>
Date: Wed, 20 Jul 88 22:58:48 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I share Joe Ginder's view that we ought to encourage Common Lisp
implementors not to cons promiscuously, but I don't think that such
non-binding encouragements belong in the standard, and I don't think we
ought to make cons-avoidance a requirement. Users, and particularly large
vendors like Inference, should consider consing behavior as an important
criterion in choosing a Lisp, and should let vendors know that this is
at least as important to them as shaving a few microseconds off TAK.
If the standard is going to contain such encouragements, we should also
encourage implementors to be fast, stick to the standard, produce excellent
documentation, and fix bugs within ten days...
-- Scott
∂21-Jul-88 0623 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88 06:23:28 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 01:06:51 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Wed, 20 Jul 88 18:32:00 -0400.
<19880720223239.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 01:06:44 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Dave,
I think that the problem here is that we see rather different classes of
programs and programmers. At Symbolics and some of the big toolkit
vendors, most of the code that is written has to be portable to all known
file systems. You people big, nasty portability problems to solve and you
want better tools for this. If that means that lots of existing code has
to be broken and extremely counter-intuitive conventions have to be
adopted, well, that's a small price to pay. And to you it seems obvious
that the case-hacking versions of of the pathname functions should get the
good names, since any code that is not portable to every known file system
is "second-class", to use KMP's label.
I see a different environment. When I'm writing application code for my
own use, or for that of my colleagues at CMU, I want that code to be
portable across several different Common Lisp systems, but all of the file
systems around here are unix-like in their treatment of case. In the
unlikely event that anyone wants to port this code to a TOPS-20 system,
they'll have to spend ten minutes fixing up a few pathname fields; I'm not
going to worry about that right now. I'm not opposed to making things
portable across very different file systems, but I put a lower value on
this than the people who do it for a living. I don't want to achieve this
goal in a way that breaks a lot of existing code and that uses syntactic
conventions that are going to confuse Lispers for generations to come. I'm
not alone -- lots of people are working in environments where all the file
systems are similar in their treatment of case.
OK, let's accept that we need to solve this portable-case problem and see
if there is some less obnoxious way to do it. Some ideas:
1. Nobody has responded to my suggestion that we add a :CANONICAL-CASE
keyword to MAKE-PATHNAME, which defaults to NIL. If non-nil, this says
that all the field-name string are to be converted to canonical case. If
we do it this way, we break no existing code. New users and those writing
non-portable code would leave this off, and their field-name strings would
not change case in mysterious ways. This would eliminate most of the
potential confusion I described in my previous note.
2. Same suggestion, but a non-nil :CANONICAL-CASE argument says to process
the fields the way KMP proposes: canonicalize, anti-canonicalize, or keep
the string as-is, depending on its case. This gives us more flexibility
that option 1, though it is more complicated. Again, this breaks no
existing code, and mysterious case-conversions don't happen until you ask
for them; at that point, you'd better have read the manual. I suppose that
the accessor functions for pathname fields also need a keyword or optional
arg saying to do the hairy case conversions.
3. Make two sets of functions, one set handling the field names verbatim
and the other doing Symbolics-style case conversion. But leave the good
names (the current ones) with the current non-converting definitions.
Again, we break no existing code and naive users are less likely to land in
the deep guano. Sophisticated users writing ultra-portable code might have
to type a little more, but not a lot more, and such people are probably
clever enough to use word-abbrev mode.
I could live pretty happily with any of these three solutions; I'm still
pretty unhappy with the original proposal, despite the claim that Symbolics
and maybe TI users have learned to live with this system. Have you
actually polled the people who get bug reports and who teach Lisp to your
new users to see if this convention is causing confusion?
-- Scott
∂21-Jul-88 0643 CL-Cleanup-mailer Re: proposal: eliminate forced consing
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 21 Jul 88 06:43:27 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Jul 88 23:12:33 EDT
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
Subject: Re: proposal: eliminate forced consing
In-reply-to: Your message of Wed, 20 Jul 88 15:00:44 -0700.
<8807202200.AA15976@trwrb.TRW.COM>
Date: Wed, 20 Jul 88 23:12:29 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I wonder if anyone would use this TARGET stuff once we have a good
iteration facility built into the language. I suspect that the existing
sequence functions will end up being used only in very straightforward
cases.
-- Scott
∂21-Jul-88 0803 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88 08:03:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 07:59:17 PDT
Date: 21 Jul 88 07:59 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: more on BOGUS-FIXNUMS
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Tue, 19
Jul 88 14:49:19 MDT
To: sandra%cdr@cs.utah.edu
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880721-075917-3637@Xerox>
I think the SIGNED-INTEGER stuff is a little like PROCEDURE; there seems to be
some sentiment for just patching what we have rather than introducing new names,
especially where they are close.
I like #3; there's some precedent for turning a ClTl's "typically" to a firm
requirement where it encourages portability and there doesn't seem to be any
reason to avoid it. We must be specific about the "n". I'd propose "14", i.e.,
FIXNUMs must be a supertype of (SIGNED-BYTE 14). That's small enough not to give
even today's micros heartburn, and large enough to avoid having people squawk
too much. It is consistent with current practice, and removes some of the
potential portability requirements.
While we're at it, let's make FIXNUM a built-in class for CLOS? If its useful
for discrimination, and implementations have 'em, then why not be able to CLOS
them too?
If you want to get rid of something, get rid of BIGNUM. It doesn't fit into the
class hierarchy as nicely, you don't want to use it for class discrimination
(since it is (AND INTEGER (NOT FIXNUM)) and might really represent several
implementation types.)
∂21-Jul-88 0814 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88 08:14:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 08:09:56 PDT
Date: 21 Jul 88 08:09 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 21 Jul 88 01:06:44
EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880721-080956-3657@Xerox>
I'd go for your #1 or #2.
∂21-Jul-88 0825 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88 08:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 436512; 21 Jul 88 11:23:58 EDT
Date: Thu, 21 Jul 88 11:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Jul 88 01:06 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <19880721152341.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 01:06:44 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
....If we do it this way, we break no existing code....
You mean we break none of -your- existing code. The only way to break no
existing code is to retain the unsatisfactory status quo. Since CLtL is
not specific here, different implementations have resolved the ambiguity
in different ways, and if they are to be made all to work the same way,
some existing code will have to change.
If the above has an obnoxious tone, it's not intentional. I simply mean
to point out that what you said is not accurate.
∂21-Jul-88 0833 CL-Cleanup-mailer [Masinter.pa: Re: questions]
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88 08:33:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 08:20:56 PDT
Date: 21 Jul 88 08:20 PDT
From: Masinter.pa@Xerox.COM
Subject: [Masinter.pa: Re: questions]
To: CL-CLEANUP@SAIL.STANFORD.EDU
Message-ID: <880721-082056-3692@Xerox>
I should have cc'd this group on these, I think.
----- Begin Forwarded Messages -----
Date: 21 Jul 88 07:48 PDT
From: Masinter.pa
Subject: Re: questions
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 19 Jul 88 13:55
To: chapman%aitg.DEC@decwrl.dec.com
Are the return values for close, in-package, inspect,
provde, and require specified?
My guess is that close returns the stream, in-package returns the new pacakge,
inspect returns the item inspected (or a new item if your inspector allows
that), and provide and require return no values. Lets bundle them together until
someone asks to separate them.
Is there a list of allowed query functions against a closed file?
Not that I know of. You mean a stream that is the result of OPEN (since we've
established that where CLtL says file it might be OK to talk to Unix's /dev/null
but not a make-two-way-stream thing). You might want to make a best guess and
circulate them.
On page 354, "When the @xlisp printer types out the name of a
special character, it uses the same table as the @f[#\] reader;
therefore any character name you see typed out is acceptable as
input (in that implementation). Standard names are always
preferred over non-standard names for printing."
I'd like to change the last sentence to read "... are required
over non-...". Do you see a problem with that?
Well, I thought preferred was put there for a reason, and I can imagine
situations where a short-name might be preferred (the case I have in mind is
NewLine. If you're running on a system that talks both to cr and lf based file
systems, you might want to emphasize #\cr #\lf vs #\newline.)
On page 160,
"@f[(ignore @i[var1] @i[var2] ... @i[varn])] affects only variable
bindings and specifies that the bindings of the specified
variables are never used. It is desirable for a compiler to issue
warning if a variable so declared is ever referred to or is also
declared special, or if a variable is lexical, never referred to,
and not declared to be ignored."
Where is "issue a warning" defined? Should it be defined by the standard?
The compiler committee, bless their collective hearts, are supposed to help with
this issue. What the charter of the compiler is, what warnings it can and cannot
issue, is not specified well enough, which is why this is fuzzy. I'd suggest
editorially that you move this to a section on Compiler Operations (with a
forward reference to it) to give them something to focus on; what is and isn't
allowable behavior for a compiler should be separated from the semantics of the
language, however.
One possibility is to establish another kind of error situation, a "warnable
condition", that is, something that is legal within the formal semantics of the
language but that a user might expect a compiler to warn about, including misuse
of ignore, a call to
(+ 3 T) or some such. But I'm reaching.
On page 24,
"Symbols have a component called the @i[property list], or @i[plist].
By convention this is always a list whose even-numbered
components (calling the first component zero) are symbols,
here functioning as property names, and whose odd-numbered components
are associated property values. Functions are provided for manipulating
this property list; in effect, these allow a symbol to be treated as an
extensible record structure."
Can I change the "by convention" to say "it is required" or something like
that?
Well, one of the cleanup proposals was discarded because (someone) asserted that
CLtL required property lists had to have an even number of components. I'm less
sure about GETF, which doesn't operate on symbol property lists.
On page 67,
"Other implementation-dependent bookkeeping actions may be taken as well
by @f[defun]."
Can I leave this out?
I think so.
Where a result is not specified to be a copy,
does that mean it can or can't be, or that it's not allowed?
I think it means that it can or can't be. That's been the interpretation for
lots of things, that it was deliberately left unspecified.
The following have underspecified arguments:
logbitp
make-dispatch-macro-character
make-hash-table
make-sequence
make-string
nthcdr
parse-integer
Should I choose the "obvious" specification for the arguments or
generate clean-up proposals for each one?
I think you should (a) choose the obvious specification, and (b) circulate a
single omnibus document saying that these are the editorial choices you've made,
anyone who wants to hear about the issues on any of them, we'll write it up in
full "cleanup" form. I don't want to bog down the process with stuff that isn't
controversial, however.
When it is stated that a function supplied to another function
(e.g. merge) "should not have any side effects", does that mean
"it is an error for the function to have side effects", or does it
mean that if the function has side effects, the result will be
implementation-dependent?
I'm a little fuzzy on the distinction between "it is an error" and "if you do
it, the results are implementation-dependent".
----- End Forwarded Messages -----
∂21-Jul-88 0936 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Jul 88 09:36:18 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA24684; Thu, 21 Jul 88 10:35:57 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA01506; Thu, 21 Jul 88 10:35:53 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807211635.AA01506@cdr.utah.edu>
Date: Thu, 21 Jul 88 10:35:52 MDT
Subject: Re: more on BOGUS-FIXNUMS
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM, 21 Jul 88 07:59 PDT
> Date: 21 Jul 88 07:59 PDT
> From: Masinter.pa@Xerox.COM
>
> I like #3; there's some precedent for turning a ClTl's "typically" to
> a firm requirement where it encourages portability and there doesn't
> seem to be any reason to avoid it. We must be specific about the "n".
> I'd propose "14", i.e., FIXNUMs must be a supertype of (SIGNED-BYTE
> 14). That's small enough not to give even today's micros heartburn,
> and large enough to avoid having people squawk too much. It is
> consistent with current practice, and removes some of the potential
> portability requirements.
This is also my favorite alternative (next to removing FIXNUMs
entirely, that is).
Actually, I don't think we have to worry particularly about supporting
micros. According to Stan, it appears that the Lisp with the smallest
fixnum range is actually Franz Lisp, which uses a separate spaces
implementation with fixnums in the range [-1024, 1023]. Here are some
fixnum sizes for Lisp implementations that run on micros or otherwise
claim to be "small":
Cambridge Lisp 24 bits
PC Scheme 15 bits
XLisp C "long" (boxed, no bignums)
VT-Lisp no integers, all numbers are Pascal "real"s
A-Lisp 30 bits (immediate, no bignums)
Stan says Gold Hill would not disclose information about their
implementation. It looks like all of other Lisp implementations he
was able to gather information on which claim to be Common Lisps (or
even subsets of Common Lisp) have fixnums at least 24 bits long.
Therefore, unless somebody comes up with a counterexample, I think we
could safely retain the N=16 from CLtL.
-Sandra
-------
∂21-Jul-88 1044 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88 10:44:00 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436601; Thu 21-Jul-88 13:43:43 EDT
Date: Thu, 21 Jul 88 13:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880721134308.5.KMP@PEWEE.SCRC.Symbolics.COM>
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards. For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
CL code needs to at least be able to detect and possibly to manipulate
such wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTION):
Introduce the following function:
WILD-PATHNAME-P pathname &optional field-key [Function]
Tests a pathname for the presence of wildcard components.
If the first argument is not a pathname an error is signalled.
If no field-key is provided, or the field-key is NIL, this function
returns true if the argument pathname has any wildcard components.
Otherwise, it returns false.
If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
if the argument pathname is wild in the indicated component. Otherwise,
it returns false.
Test Case:
#1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
#2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
#3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
#4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
#4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
Rationale:
If the programmer can at least detect wild pathnames reliably,
he can know to do something useful (give up, merge out the bothersome
components, call DIRECTORY for a list of matching pathnames, etc.)
Current Practice:
Presumably no implemenation supports the proposal exactly as stated.
Symbolics Genera provides the ability to do
(SEND pathname :WILD-P)
which returns a value such as NIL, :NAME, :TYPE, etc. In the case
that more than one field is wild, however, some information is lost.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcarded code to write it (often more heuristically).
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
situations which CL pathnames cannot represent.
Benefits:
Portable user interfaces that prompt users for pathnames could more
reliably detect wildcard pathnames and more easily guard against
embarrassing behavior in such situations.
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
Pitman supports PATHNAME-WILD:NEW-FUNCTION.
If someone wanted to argue that this function should accept strings and such,
coercing its argument to a pathname, I wouldn't object too strenuously. That
would entail adding an optional host argument, though.
∂21-Jul-88 1205 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 21 Jul 88 12:04:07 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06633; 21 Jul 88 19:56 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 21 Jul 88 19:52:13 BST
Message-Id: <10668.8807211852@subnode.aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu
> Date: 21 Jul 88 07:59 PDT
> From: Masinter.pa@com.xerox
> I like #3; there's some precedent for turning a ClTl's "typically" to
> a firm requirement where it encourages portability and there doesn't
> seem to be any reason to avoid it. We must be specific about the "n".
> I'd propose "14", i.e., FIXNUMs must be a supertype of (SIGNED-BYTE
> 14).
It may seem perverse to say so, but I'm not sure this would be an
improvement, for it would provide an implementation with 14-bit
fixnums with what they might regard as sufficient defense: they
strictly conform to the standard. I have similar fears about the 1024
minimum for array-dimension-limit and array-total-size limit. I don't
usually make sure my CL programs will run in a system where arrays
can't have more than 1024 elements, and if I did want to be sure I'd
look at the actual limit, not 1024. But I'd probably complain if the
limit really were so low, and it somehow seems easier to say an
implementation's low limit is pretty rediculous when it isn't
explicitly sanctioned by the standard. Perhaps if the minimums
were a little bigger...
Anyway, I favor a consistent policy on limits of this sort. If we
have them for arrays, we can (should?) have them for fixnums.
∂21-Jul-88 1211 CL-Cleanup-mailer proposal: eliminate forced consing
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88 12:11:27 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436665; Thu 21-Jul-88 15:07:09 EDT
Date: Thu, 21 Jul 88 15:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal: eliminate forced consing
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8807202200.AA15976@trwrb.TRW.COM>
Message-ID: <880721150632.7.KMP@PEWEE.SCRC.Symbolics.COM>
Or we might just use the type argument and the new CLOS type EQL:
(LET ((X (MAKE-STRING 3 :INITIAL-ELEMENT #\a)))
(EQ (MAP `(EQL ,X) #'CHAR-UPCASE X) X))
:-)
[I have not yet formulated a serious opinion on this issue.]
∂21-Jul-88 1302 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 13:01:43 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 16:00:21 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Thu, 21 Jul 88 11:23:00 -0400.
<19880721152341.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 16:00:02 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Date: Thu, 21 Jul 88 01:06:44 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
....If we do it this way, we break no existing code....
You mean we break none of -your- existing code. The only way to break no
existing code is to retain the unsatisfactory status quo. Since CLtL is
not specific here, different implementations have resolved the ambiguity
in different ways, and if they are to be made all to work the same way,
some existing code will have to change.
Well, what I really meant was that we break no existing Common Lisp code,
where by "Common Lisp" code I mean code written according to any reasonably
straightforward interpretation of what is in the manual. It hadn't
occurred to me that you folks at Symbolics consider the system describeed
by KMP to be in compliance with CLtL and not an extension -- a worthwhile
extension and perhaps even a necessary extension, given the problems you
want to solve. KMP did label his proposal a "change" rather than a
"clarification", though I see that he claims in the discussion section that
it is technically in compliance with CLtL. I have some doubts about
that claim, but let's not argue about that.
So, as you say, some of us are going to have to fix some existing code if
we try to standardize this situation. If we have a way -- either a switch
or a separate set of functions -- to select either canonicalizing or
verbatim interpretations, whoever has to change his code can do so with a
simple editor macro.
So the only thing we're really fighting about is who gets the good function
names or the default version of switchable functions. I still think that
the princple of least astonishment suggests that these field names ought to
be used verbatim unless the user specifically asks for canonicalization of
case. We can make it easy to ask for the canonicalizing behavior (my
proposal 2 does that), but it shouldn't be the default.
One other suggestion: Whether we go with KMP's proposal or something like
my proposal 2, I think that we should use all-lower-case to indicate
canonical case, and all-upper to indicate anti-canonical case. As someone
pointed out in an earlier message, this choice is arbitrary. Other things
being equal, we may as well go with the arbitrary choice Symbolics made,
but other things are not equal. Unix, the herpes of operating systems, is
still spreading and is going to be the file system most Lisps have to deal
with for at least the next 5 years, and probably 10. Tops-20 is almost
dead, and I don't know of any other default-upper-case file systems that
are on the rise, at least in the communities to whom Lisp is important. So
let's make the choice that minimizes the number of people who have to type
things in a case that is the opposite from what they want. Of course, this
choice breaks some existing code, but we've already agreed that that is
necessary.
-- Scott
∂21-Jul-88 1308 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Jul 88 13:07:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 JUL 88 12:55:03 PDT
Date: 21 Jul 88 12:56 PDT
From: masinter.pa@Xerox.COM
Subject: Re: more on BOGUS-FIXNUMS
In-reply-to: sandra%cdr@cs.utah.edu (Sandra J Loosemore)'s message of Thu, 21
Jul 88 10:35:52 MDT
To: sandra%cdr@cs.utah.edu
cc: Masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <880721-125503-4335@Xerox>
Xerox Common Lisp has 17-bit fixnums. LISP:MOST-POSITIVE-FIXNUM = 65535,
LISP:MOST-NEGATIVE-FIXNUM = -65536.
∂21-Jul-88 1351 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 13:51:20 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 16:50:13 EDT
To: Masinter.pa@Xerox.COM
cc: sandra%cdr@cs.utah.edu, cl-cleanup@sail.stanford.edu
Subject: Re: more on BOGUS-FIXNUMS
In-reply-to: Your message of 21 Jul 88 07:59:00 -0700.
<880721-075917-3637@Xerox>
Date: Thu, 21 Jul 88 16:49:53 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I agree with Larry and GZ on this.
-- Scott
∂21-Jul-88 1417 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88 14:17:45 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436759; Thu 21-Jul-88 17:16:58 EDT
Date: Thu, 21 Jul 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: The message of 21 Jul 88 16:00 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 16:00:02 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
... I still think that the principle of least astonishment suggests
that these field names ought to be used verbatim unless the user
specifically asks for canonicalization of case. We can make it easy
to ask for the canonicalizing behavior (my proposal 2 does that), but
it shouldn't be the default.
There's another theory that says that if he's going to be astonished,
let it happen early. The stated purpose of CL is to provide for the
development of portable programs. If you do a non-portable thing that
kinda feels right and implementations are encouraged to accept it without
warning and you have to know to say something magic to get something
portable, then you don't have a portable language and you don't encourage
portable programs.
Consider that we could have had a :PORTABLE keyword argument on all
functions. Any time you wanted to opt for portable behavior, you could
ask for it. Then everyone could write
(DEFUN FOO (X Y Z)
(* (+ X Y :PORTABLE T) Z :PORTABLE T))
and when people didn't ask for portability, they wouldn't have to put up
with it. You'd get a lot jazzier functionality out of things, and people
would stop complaining about implementations that provided `gratuitous
extra functionality' because that would be the encouraged thing. For example,
(DEFUN FOO (X Y Z)
(* (+ X Y) Z))
-- without the :PORTABLE T arguments -- could be a lot faster because then
you could always use native arithmetic. Don't think there aren't CL
implementations which do almost just this (eg, they don't implement fixnums).
Plenty of people find it unintuitive that in present-day CL
(* (THE FIXNUM X) (THE FIXNUM Y))
doesn't use a fixnum-multiply instruction (because you didn't type
declare the return value) but we just went and defined it in a way that we
knew it was important for it to work, even if it didn't come up too often.
Sorry about those short-sighted who get confused but having the language be
well-defined in a portable way is just more important. Some people are mad,
too, because they think they know the processor type they're on and know
what to expect from the fixnum-multiply instruction, but we've already made
the decision that supporting that activity just wasn't CL's priority.
We invented CL just -exactly- to get away from nonsense where an
implementor's interpretations were preferred over the needs of a community.
The default just has to be the thing which promotes portable applications.
If it's not, you can't test programs in one environment and have any
hope that it will therefore run in another.
It's true that in general there is no reference implementation of CL,
nor is one possible, and running your program in one implementation
cannot be a guarantee that it will run in another, but that's nothing to
cheer about. That's just a sad thing we should be trying to minimize
rather than institutionalize.
And you just never know when your company or university might fold,
you might get tired of what you're doing and decide to move, or your
company might find itself on different hardware/os/file-system than
it ever thought possible ... and you might be happy you were made to
design in a feature that you never originally thought had a personal
meaning to you. [Certainly this happened to me when I moved from
ITS/Tops-20 file servers at MIT to Lispm/VMS/Unix ones at Symbolics.]
... Whether we go with KMP's proposal or something like my proposal 2,
I think that we should use all-lower-case to indicate canonical case,
and all-upper to indicate anti-canonical case. ...
There are already several places where this arbitrary decision has been
made in Lisp. The decision has been made consistently, and I think that's
useful. I would hate to go against the grain:
* Uppercase is the canonical case for non-backslashed symbols seen by
the reader. eg, (symbol-name 'xyz) => "XYZ". (p168, p367, ...)
* Uppercase is the canonical case for dispatch readmacros. eg, the chars
received as arguments by # readmacro functions will have been upcased.
The "a" in #a will be seen by the function supporting #a as #\A, not
#\a. eg, see SET-DISPATCH-MACRO-CHARACTER (p364).
* Uppercase is the default case for the Lisp printer. The default value
of *PRINT-CASE* is :UPCASE (p372).
You may be surprised to learn that I almost exclusively use file systems
where lowercase or mixed case is culturally preferred. My intent here is
not to force people to use uppercase filenames, or to assert that using
uppercase as a canonical internal case is no problem when I have no
experience with it. I use it daily and can't recall any problem with using
uppercase because
- the only situations where it comes up is when I'm dealing with things
I conceptualize as abstract primitives. I write (load "s:>kmp>foo.lisp")
or (load (make-pathname :name "FOO" :type :lisp)), depending on what is
appropriate for the application.
- it really does feel consisent with the canonical case for other things
elsewhere in the language.
You can make whatever arguments you want about the prevalence of Unix, but
I don't think our language design has any business catering to a particular
style. The argument we make for the choice of canonical case should be
defensible in the abstract.
To me, the really compelling argument in this regard is the following:
* Uppercase is the canonical case for spoken language.
this is not a syntactically well-formed english sentence.
THIS IS A SYNTACTICALLY WELL-FORMED ENGLISH SENTENCE.
Compatible with Unix or not, this is at least a position which can be defended
in the abstract.
∂21-Jul-88 1515 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 21 Jul 88 15:13:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07572; 21 Jul 88 23:05 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 21 Jul 88 23:01:09 BST
Message-Id: <11002.8807212201@subnode.aiai.ed.ac.uk>
To: KMP@scrc-stony-brook.arpa, Moon@scrc-stony-brook.arpa,
Scott.Fahlman@b.gp.cs.cmu.edu, masinter.pa@xerox.com
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Cc: CL-Cleanup@sail.stanford.edu
Scott's porposals (1 and 2) for a :canonical-case keyword seem worth
considering, but whether 1 or 2 is better is less clear. I'm still
not sure what anti-canonical accomplishes. On a system that accpts
only one case, it can do nothing; on a system that accepts any case,
why change case at all? Why not use whatever the user provides? Some
case will be more common, but if we're trying to ignore the details of
the FS do we care? OK, anti-canonical matters so I can still get that
case if I want it, and pathnames need to be able to represent such
namestrings. 2 then?
I do think this goes back to a question of exactly what portibility
gain is involved. I can see that the Symbolics system does a number
of useful things, but I'm not sure how much each individual thing
does in isolation.
Moreover, pathnames are not useless without this change. They are a
more sturctured representation than namestrings, and save one from
parsing. Code that does not aspire to complete portability might
nonetheless use them. There may also be code that wants to be
portable to different Unix systems, say, where the case problem will
not arise, or between different common lisps that parse namestrings
differently or single lisps that refuse to parse them "correctly"
(Unix names like ".lisprc", say, want to be merge-pathname'd as names
not types.)
> Date: Wed, 20 Jul 88 18:32 EDT
> From: "David A. Moon" <Moon@arpa.scrc-stony-brook>
> The second comment is that it is in fact both possible and useful to
> make pathnames themselves portable. That would be the subject of a
> separate proposal. Again, this has been current practice in both
> Symbolics and TI systems since before Common Lisp even existed, and
> works quite well. The interested reader can consult the documentation
> of "logical pathnames" for either of those systems.
Done.
> Basically the idea is to have an imaginary file system that behaves in
> the same way everywhere, and that puts files in the same place
> everywhere. Then at each location one defines a set of translations
Isn't this independent of pathnames per se? (I.e., couldn't it be
done just by having a convention for namestrings?)
And I still have difficulty imagining interesting things portable
programs can do without such a convention (apart from the things
pathnames already provide, such as parsing). Or, perhaps I should say
I have difficulty imagining interesting things made possible by the
canonical case proposal. I can easily see the virtues of canonical
types. But the gain from having the case made magically right seems
small.
-- Jeff
∂21-Jul-88 1537 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Jul 88 15:37:00 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00913; Thu, 21 Jul 88 18:35:01 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA03624; Thu, 21 Jul 88 18:38:31 EDT
Message-Id: <8807212238.AA03624@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: CL-Cleanup%SAIL.STANFORD.EDU@multimax
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-Reply-To: Your message of Thu, 21 Jul 88 17:16:00 -0400.
<880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 18:38:24 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Date: Thu, 21 Jul 88 17:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
... Whether we go with KMP's proposal or something like my proposal 2,
I think that we should use all-lower-case to indicate canonical case,
and all-upper to indicate anti-canonical case. ...
There are already several places where this arbitrary decision has been
made in Lisp. The decision has been made consistently, and I think that's
useful. I would hate to go against the grain:
I hate to agree with Kent here because I really prefer lower case for
everything possible, but he's right. The decision to make uppercase
the default in Common Lisp was probably a mistake, but it's a mistake
we're stuck with. Inconsistency is worse.
∂21-Jul-88 1546 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Jul 88 15:46:02 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 436854; Thu 21-Jul-88 18:43:52 EDT
Date: Thu, 21 Jul 88 18:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, Scott.Fahlman@b.gp.cs.cmu.edu,
masinter.pa@xerox.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: <11002.8807212201@subnode.aiai.ed.ac.uk>
Message-ID: <880721184315.3.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 23:01:09 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
... And I still have difficulty imagining interesting things portable
programs can do without such a convention (apart from the things
pathnames already provide, such as parsing). Or, perhaps I should say
I have difficulty imagining interesting things made possible by the
canonical case proposal. I can easily see the virtues of canonical
types. But the gain from having the case made magically right seems
small. ...
I'd wager that there is a sizable number of TOPS-20 users out there who
don't know that the TOPS-20 file system admits lowercase names. The only
trouble is that to refer to such a filename in any of the normal TOPS-20
programs, you have to quote every character with Control-V.
Sure, you can say that (MAKE-PATHNAME :TYPE "foo" :VERSION "lisp") should
just create a file called "foo.lisp" on Unix and "foo.lisp" on TOPS-20 and
that should be fine for "portable" programs, but it's not because you have
to tell Emacs
c-X c-F c-V f c-V o c-V o . c-V l c-V i c-V s c-V p
every time you want to edit the file. This is very unnatural even for people
who know it's what must be done. But for people who don't know it must be
done, they just wonder why "foo.lisp" shows up in their directory listing
but doesn't appear to be something they can edit or delete from outside of
Lisp!
The value you get from having canonical case is that files get created in
a natural way on any operating system.
It also turns out that this just makes file merging a lot simpler.
Consider an operation I do a lot on a day-to-day basis, which takes
advantage of the canonical type and canonical case issues:
Command: Copy File (from) MYUNIX:/foo/bar/zap.l (to) MY20:
Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>ZAP.LSP.0
rather than:
Copying MYUNIX:/foo/bar/zap.l to MY20:<FOO.BAR>↑Vz↑Va↑Vp.↑Vl.0
which we might have if neither of these proposals passed.
Sure, you can say that the Copy File command could go to massively more
work using system-dependent knowledge to do all the case foolery to get
machine-to-machine copying correct, but the fact of the matter is that
if all this stuff were defined correctly, you could write COPY-FILE in
nearly portable code (I say nearly only because I'm glossing byte-size
issues, an orthogonal problem):
(WITH-OPEN-FILE (FROM-STREAM FROM :DIRECTION :INPUT)
(WITH-OPEN-FILE (TO-STREAM (MERGE-PATHNAMES TO FROM)
:DIRECTION :OUTPUT)
(STREAM-COPY-UNTIL-EOF FROM-STREAM TO-STREAM)))
and everything else takes care of itself. You could also argue that the
hair belongs in MERGE-PATHNAMES but why make work for yourself? There
only needs to be hair at all if you can't get agreement on some trivial
issues, such as those on the floor. If we can just agree on these
details, then no programs will need to have any hair -- things will
just work out.
∂21-Jul-88 1633 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Jul 88 16:31:46 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 21 Jul 88 18:08:44 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Thu, 21 Jul 88 17:16:00 -0400.
<880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Thu, 21 Jul 88 18:08:29 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Let me see if I understand the philosophy underlying your argument. It
seems to go as follows:
1. There are certain complex and difficult things that a Common Lisp
programmer must do in order to be sure that his code will be absolutely
portable across all known file systems, living and dead.
2. Some people believe that they don't care about that kind of portability.
If given a choice they will not worry about these painful and complex
things.
3. *WE* know that this attitude is short-sighted, so we should try to
remove the temptation to cut corners. In this case, the best way to do
that is to make sure EVERYONE has to deal with these portability issues all
the time, whether they want to or not.
4. In the end, they'll thank us for saving them from their baser
instincts.
-- or, more briefly --
Nobody ever expects the Spanish Inquisition!!!
Well, I've said my piece, and will abide by the decision of the committee.
If you and Moon can persuade some of the non-Symbolics people on the
committee that the good names should go to the portable case-bashing
versions, I'll disagree, but I can live with it.
-- Scott
P. S. I don't agree with your "really compelling argument" about natural
language. I don't think that an all-upcase sentence is any more
syntactically correct than an all-lower-case one. But that's not
important, since your arguments about upper-case being the default
elsehwere in the language is a pretty good one.
∂22-Jul-88 0642 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Jul 88 06:42:03 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Jul 88 09:40:55 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Your message of Thu, 21 Jul 88 17:16:00 -0400.
<880721171622.0.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 09:40:41 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
After sleeping on it, I've decided that my arguments against your "Spanish
Inquisition" philosophy, forcing users to do everything in a portable way
aaginst their will, were silly. As you say, Common Lisp does indeed make
people go the long way round in dozens of places in the language, all for
their own good and for greater portability.
The only difference here is that the need for porting code to file
systems of different case comes up much less often than other kinds of
porting issues, and many of us may never be faced with this; if we are,
it's easy to find and fix the problems. And I still think it's a confusing
choice to use the case of a field to signal how you want the case to be
altered, though perhaps not fatally confusing. I retain a mild preference
for giving the default names to the verbatim versions, but can live with
either choice.
-- Scott
∂22-Jul-88 0649 CL-Cleanup-mailer FIXNUM's aren't Bogus!
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 06:49:16 PDT
Received: by labrea.stanford.edu; Fri, 22 Jul 88 06:47:52 PDT
Received: from bhopal.lucid.com by edsel id AA07179g; Fri, 22 Jul 88 06:39:24 PDT
Received: by bhopal id AA04492g; Fri, 22 Jul 88 06:40:17 PDT
Date: Fri, 22 Jul 88 06:40:17 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8807221340.AA04492@bhopal.lucid.com>
To: masinter.pa@xerox.com
Cc: jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk, sandra%cdr@cs.utah.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 21 Jul 88 12:56 PDT <880721-125503-4335@Xerox>
Subject: FIXNUM's aren't Bogus!
re: Xerox Common Lisp has 17-bit fixnums. LISP:MOST-POSITIVE-FIXNUM = 65535,
LISP:MOST-NEGATIVE-FIXNUM = -65536.
This choice is quite arbitrary. FIXNUM is not constrained to mean
"immediate" data type (indeed it was NOT an immediate in PDP10 MacLisp),
and Xerox Lisp's FIXP could just have well been included in its FIXNUM
type; that would have yielded a range of 32 bits rather than 17. At one
time, at least some implementations of Interlisp-D had microcode to cover
the case of FIXP's; so it was a relatively efficient type.
MacLisp may be considered to be the father of the modern FIXNUM -- it
originated the trick of reserving a couple pages of write-protected memory
filled in with a dense neighborhood of integers centered around 0; thus
"consing" a small fixnum didn't require new storage allocations. The
critical meaning for FIXNUM's, however, is not merely that they be "small",
nor that basic operations on them not consume storage, but that they be
operable in a few, fixed number of steps. In fact, in compiled code, the
basic operations (on fixnums) were always one PDP10 instruction [including
the four rationals, shifting, and even HAULONG, the predecessor of CL's
INTEGER-LENGTH. Love that JFFO!] A *uniform* representation for fixnums
was the critical factor in compiling these operations into one machine
instruction.
The opposite of FIXNUM is thus a datum that falls into the asymptotic
algorithms of "bignums", whose operational timing is proportional to the
length of the numbers involved.
I propose this meaning for FIXNUM: that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11.
I would _prefer_ that the range of positive FIXNUM's be at least as large
ARRAY-TOTAL-SIZE-LIMIT, so that one can be assured that any legitimate
array index is a FIXNUM. However, I'll admit that this is of more
concern to an implementation on "stock" hardware with "general purpose"
indexing registers.
Regarding the portability issues raised by differing FIXNUM ranges --
I agree with all of Jeff Dalton's comments. Championing portability
here is making a mountain of a molehill.
-- JonL --
P.S. A candidate for early fixnums might also be Interlisp-10's assymetric
representation, wherein very small integers were "immediate" and
medium-sized integers fit into one word (maybe Lisp1.5 had a similar
scheme too?). Although operating on such a representation did not
require use of an "asymptotic" algorithm, it did require so much more
time than the PDP10 MacLisp scheme that they were not considered
particularly "efficient" by the relevant community of users. In fact,
just decoding the representation cost a subroutine call. [Who among
us remembers (JSP T, NUMVAL)?]
P.P.S. The more common technique now for representing fixnums is to
notice that on byte-addressed machines (like VAX, MC68000 series,
INTEL 80386, most Risc-type machines, etc.) the low-order two bits
or more of an address are redundant (cons cells requiring at least 4
and probably 8 bytes of memory). So the low-order two or three bits
can be used arbitrarily as datatype tag information, and a prudent
choice of the tag code leads to a very efficient FIXNUM implementation.
Let fixnums have all "low-order" bits zero; thus data in a format like:
sxxx...xx0...0
(where "s" is a sign bit and the "x"'s are arbitrary bits) will still
be in that format after a machine "longword" addition or subtraction;
and multiplication and division require at most a pre- or post- shift
by a couple bits to retain that format. Hence basic fixnum operations
can still be done in about one machine instruction. [I credit Stallman
with first noticing the immense utility of this fact, back in 1978
when we were brainstorming the design of VAX/NIL]. Despite the vast
difference in implementational "tricks", PDP10 MacLisp and VAX/NIL
share what I condsider to be the fundamental feature: low, constant-
time value for basic operations costs.
∂22-Jul-88 0928 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88 09:24:11 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05507; 22 Jul 88 17:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 17:04:31 BST
Message-Id: <23641.8807221604@aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu
> Date: Thu, 21 Jul 88 10:35:52 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Subject: Re: more on BOGUS-FIXNUMS
> Actually, I don't think we have to worry particularly about supporting
> micros. According to Stan, it appears that the Lisp with the smallest
> fixnum range is actually Franz Lisp, which uses a separate spaces
> implementation with fixnums in the range [-1024, 1023].
That is not correct. Fixnums in Franz are 32 bits, or at least they
are on VAX or 68k. Look at any Franz manual or write some Franz code
that declares fixnums or uses fixed-type arithmetic if you want to
check this.
The [-1024, 1023] is for *small fixnums*. They are just like normal
fixnums but preallocated. The "separate space" notion is sometimes
used to check whether an integer is in the range of preallocated ones,
but Franz in general uses bibop (the high order bits of the address
are an index into a type table).
BTW, as I have mentioned before, Franz and KCL are vary similar in
this respect.
-- Jeff
∂22-Jul-88 0957 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 09:57:07 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26690; Fri, 22 Jul 88 10:56:43 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02382; Fri, 22 Jul 88 10:56:41 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221656.AA02382@cdr.utah.edu>
Date: Fri, 22 Jul 88 10:56:40 MDT
Subject: Re: more on BOGUS-FIXNUMS
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Fri, 22 Jul 88 17:04:31 BST
I think this is probably just a misunderstanding of terminology --
what Stan Shebs described to me as being "fixnums" are clearly not the
same beasties that you call "fixnums".
I could play devil's advocate here and point out that the confusion
over terminology tends to support my argument for getting rid of the
name "fixnum" from the language entirely; when an implementation has
several different classes of numbers, which one(s) do you call
"fixnum"? In PSL and its derivatives, for example, the class of
numbers which are called "inums" (represented as immediate data) are
more "fixnum"ish than the class of numbers called "fixnums"!
-Sandra
-------
∂22-Jul-88 1000 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:00:32 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26819; Fri, 22 Jul 88 11:00:09 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02396; Fri, 22 Jul 88 11:00:07 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221700.AA02396@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:00:03 MDT
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 1 Jul 88 19:57 EDT
I don't like this proposal at all and agree with Fahlman that it
should definitely not be the default behavior. I also believe that
there are also so many other issues unresolved with MAKE-PATHNAME that
make it practically impossible to use portably, that trying to deal with
case is rather pointless. These other issues include:
- how long the strings for each of the components can be
- what characters are valid in each component string
- whether punctuation (such as the square brackets around the
directory specifications for VMS, or the dot before the file type)
must/can be included in the component string
- whether the implementation/operating system even supports the
concept for a particular component (e.g., devices on Unix,
directories on CTSS)
These issues are handled differently even among different Lisps
running under the same operating system. As a result, I have avoided
using MAKE-PATHNAME like the plague. Instead, I use MERGE-PATHNAME to
fiddle with pathname objects created by passing namestrings to
PATHNAME. If I must hard-wire namestrings into my code, it is with
the understanding that they are specific to a particular operating
system. I assume that PATHNAME does any canonicalization of case
appropriate for that Lisp implementation and operating system. This
approach has been working quite well for me and I would be content
to leave things as they are, perhaps adding only stronger wording in
the standard about how nonportable MAKE-PATHNAME is. Or, perhaps
MAKE-PATHNAME should be removed from the language entirely.
-Sandra
-------
∂22-Jul-88 1001 CL-Cleanup-mailer Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:01:27 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26844; Fri, 22 Jul 88 11:00:59 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02402; Fri, 22 Jul 88 11:00:56 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221700.AA02402@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:00:55 MDT
Subject: Re: Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 5 Jul 88 14:56 EDT
I've never had any need for this functionality and am not convinced it
is really that important. However, I don't have any strenuous
objections to the content of the proposal.
-Sandra
-------
∂22-Jul-88 1002 CL-Cleanup-mailer Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:02:36 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26901; Fri, 22 Jul 88 11:02:14 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02408; Fri, 22 Jul 88 11:02:09 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221702.AA02408@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:02:08 MDT
Subject: Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 7 Jul 88 11:23 EDT
Of the options presented for this issue, I prefer
PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION. The NAMESTRING-COERCION
option seems like it is really the wrong time, and I would rather not
leave it EXPLICITLY-VAGUE.
However, I would really like to see something completely different --
namely adding a keyword argument to TRUENAME to allow it to be used
for explicit syntax checking of filenames without signalling an error
if the file doesn't exist. Functions such as OPEN and the ones in
sections 23.3, 23.4, and 23.5 that actually pass pathnames to the host
file system would be required to (implictly or explicitly) perform the
same checking.
This would also solve a problem I brought up some time ago, that I was
having with Lucid Lisp under VMS. I had defined a logical name like
LISP$LIBRARY that expanded into something that included a directory
specifier in its expansion, like disk$login:[loosemore.lisp.library].
However, I was getting things like
(namestring (merge-pathnames
(pathname "[loosemore]foo.bar")
(pathname "lisp$library:")))
=> "lisp$library:[loosemore]foo.bar"
which the file system naturally barfed on when I tried to open the
file. The problem was that Lucid's PATHNAME function was treating the
logical name like a device specification instead of expanding it.
TRUENAME would have expanded the logical name for me, but since
LISP$LIBRARY was not a complete pathname for an existing file, it
would also have signalled an error.
-Sandra
-------
∂22-Jul-88 1005 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:05:11 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA26996; Fri, 22 Jul 88 11:04:49 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02415; Fri, 22 Jul 88 11:04:47 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221704.AA02415@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:04:45 MDT
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 7 Jul 88 14:35 EDT
The problem this tries to address hasn't been a big one for me, but I don't
see any harm in adopting this proposal.
Under the "Current Practice" section, you might add that programmers
who need to do this kind of thing now typically make a constant or
global variable that is initialized to hold the right file type for
whatever implementation is being used. In fact, here is what I've
been using (which I believe was stolen from somebody else):
(defvar *binary-file-type*
#+Symbolics (make-pathname :type "bin")
#+(and dec common vax (not ultrix)) (make-pathname :type "FAS")
#+(and dec common vax ultrix) (make-pathname :type "fas")
#+pcls (make-pathname :type "b")
#+KCL (make-pathname :type "o")
#+Xerox (make-pathname :type "dfasl")
#+(and Lucid MC68000) (make-pathname :type "lbin")
#+(and Lucid VAX VMS) (make-pathname :type "vbin")
#+excl (make-pathname :type "fasl")
#+system::cmu (make-pathname :type "sfasl")
#+PRIME (make-pathname :type "pbin")
#+HP (make-pathname :type "b")
#+TI (make-pathname :type "xfasl")
"The default file type for compiled files.")
-Sandra
-------
∂22-Jul-88 1006 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:06:06 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA27004; Fri, 22 Jul 88 11:05:45 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02421; Fri, 22 Jul 88 11:05:40 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221705.AA02421@cdr.utah.edu>
Date: Fri, 22 Jul 88 11:05:38 MDT
Subject: Re: Issue: PATHNAME-WILD (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Thu, 21 Jul 88 13:43 EDT
I've never had any need for this functionality and am not convinced it
is really that important. However, I don't have any strenuous
objections to the content of the proposal.
-Sandra
-------
∂22-Jul-88 1026 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88 10:26:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 437286; Fri 22-Jul-88 13:25:37 EDT
Date: Fri, 22 Jul 88 13:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807221704.AA02415@cdr.utah.edu>
Message-ID: <19880722172514.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 11:04:45 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Under the "Current Practice" section, you might add that programmers
who need to do this kind of thing now typically make a constant or
global variable that is initialized to hold the right file type for
whatever implementation is being used. In fact, here is what I've
been using (which I believe was stolen from somebody else)....
Looks like a good argument for standardization, since I think some
of these are wrong, and it would probably take half a week to test
them all.
(defvar *binary-file-type*
#+Symbolics (make-pathname :type "bin")
#+(and dec common vax (not ultrix)) (make-pathname :type "FAS")
#+(and dec common vax ultrix) (make-pathname :type "fas")
#+pcls (make-pathname :type "b")
#+KCL (make-pathname :type "o")
#+Xerox (make-pathname :type "dfasl")
#+(and Lucid MC68000) (make-pathname :type "lbin")
#+(and Lucid VAX VMS) (make-pathname :type "vbin")
#+excl (make-pathname :type "fasl")
#+system::cmu (make-pathname :type "sfasl")
#+PRIME (make-pathname :type "pbin")
#+HP (make-pathname :type "b")
#+TI (make-pathname :type "xfasl")
"The default file type for compiled files.")
∂22-Jul-88 1133 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88 11:31:03 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05507; 22 Jul 88 17:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 17:04:31 BST
Message-Id: <23641.8807221604@aiai.ed.ac.uk>
To: Masinter.pa@xerox.com, sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu
> Date: Thu, 21 Jul 88 10:35:52 MDT
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Subject: Re: more on BOGUS-FIXNUMS
> Actually, I don't think we have to worry particularly about supporting
> micros. According to Stan, it appears that the Lisp with the smallest
> fixnum range is actually Franz Lisp, which uses a separate spaces
> implementation with fixnums in the range [-1024, 1023].
That is not correct. Fixnums in Franz are 32 bits, or at least they
are on VAX or 68k. Look at any Franz manual or write some Franz code
that declares fixnums or uses fixed-type arithmetic if you want to
check this.
The [-1024, 1023] is for *small fixnums*. They are just like normal
fixnums but preallocated. The "separate space" notion is sometimes
used to check whether an integer is in the range of preallocated ones,
but Franz in general uses bibop (the high order bits of the address
are an index into a type table).
BTW, as I have mentioned before, Franz and KCL are vary similar in
this respect.
-- Jeff
∂22-Jul-88 1259 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88 12:59:28 PDT
Received: from PEWEE.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 271610; Fri 22-Jul-88 15:30:22 EDT
Date: Fri, 22 Jul 88 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: sandra%cdr@cs.utah.edu
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8807221704.AA02415@cdr.utah.edu>
Message-ID: <880722153006.9.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 13:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 11:04:45 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Under the "Current Practice" section, you might add ...
(defvar *binary-file-type* ...)
Good point. You're not the only one.
Looks like a good argument for standardization, since I think some
of these are wrong, and it would probably take half a week to test
them all.
Just to clarify, I think Moon meant (he can correct me if I'm wrong)
that this is an argument for canonical types, not an argument for
a *binary-file-type* variable, since the same implementation may have
to talk to multiple file systems, and since different extensions may
be used in different file systems, and hence a single extension may
not be appropriate for every file system.
∂22-Jul-88 1335 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Jul 88 13:34:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 437473; Fri 22-Jul-88 16:33:48 EDT
Date: Fri, 22 Jul 88 16:33 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: sandra%cdr@cs.utah.edu, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880722153006.9.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880722203320.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 15:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 13:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 11:04:45 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Under the "Current Practice" section, you might add ...
(defvar *binary-file-type* ...)
Good point. You're not the only one.
Looks like a good argument for standardization, since I think some
of these are wrong, and it would probably take half a week to test
them all.
Just to clarify, I think Moon meant (he can correct me if I'm wrong)
that this is an argument for canonical types, not an argument for
a *binary-file-type* variable, since the same implementation may have
to talk to multiple file systems, and since different extensions may
be used in different file systems, and hence a single extension may
not be appropriate for every file system.
Well, what I meant was that some of the file types in Sandra's list are
(I suspect) not the ones that the compiler in those systems actually uses.
I wasn't thinking deeper than that.
Now, getting into details beyond what I meant, there is an argument for
canonical types because a single implementation may use multiple file
systems with different file types, and hence no single string per
implementation can work. True. That's the issue within a single
implementation. There is also the multiple implementation issue: can
all implementations agree on a single canonical type that is used as the
output of the compiler, or should there be a standardized variable whose
value is that canonical type? One might think that everyone could agree
on a single canonical type for compiler output, but in fact not all
Symbolics implementations use the same canonical type, so even within a
single vendor there is disagreement. One might think this is stupid,
but in fact Symbolics has multiple types of bin files, all(?; more than
one anyway) of which are understood by some implementations, so it's
unclear how to squeeze that into a single universal canonical type.
I suppose the people who aren't used to thinking about multiple file
systems at the same time are thoroughly confused at this point. Let me
recap:
In increasing order of abstraction:
KMP's pathname component case proposal abstracts the notion of "this
alphabetic case is the standard one, and this other case is the unusual
one". Abstracting this instead of just using strings verbatim is useful
because file systems disagree on which case is standard (Symbolics and
Unix use lower case; all major computer vendors (IBM, DEC, CDC, etc.)
use upper case. [If anyone responds with an argument about who is major
and who is minor, I will jump up and down and scream. That's not the
point.]).
Canonical types abstract the notion of "such and such pathname-type
field means such and such semantic content in the file". Abstracting this
instead of just using strings is useful because we might be dealing
with multiple file systems, each of which already has its own convention
for what the string should be.
*binary-file-type* (si:*default-binary-file-type* in Genera) abstracts
the notion of "this canonical type is the one the compiler outputs."
Abstracting this instead of just picking a standard name for this
canonical type is useful because there might be several different semantic
file types that could potentially be the output of the compiler.
Whether anyone cares about these abstractions depends, obviously, on
whether the programs they write deal with these concepts and need to
be portable across file systems and/or across implementations.
∂22-Jul-88 1346 CL-Cleanup-mailer Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Jul 88 13:46:33 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA03399; Fri, 22 Jul 88 14:45:33 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02616; Fri, 22 Jul 88 14:45:26 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807222045.AA02616@cdr.utah.edu>
Date: Fri, 22 Jul 88 14:45:25 MDT
Subject: Re: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, sandra%cdr@cs.utah.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 22 Jul 88 16:33 EDT
Sigh, I didn't mean to start a controversy on this. I just wanted to
point out that people have been able to find other solutions to the
problem this proposal is supposed to address, although the alternatives
are somewhat messier.
-Sandra
-------
∂22-Jul-88 1910 CL-Cleanup-mailer Re: more on BOGUS-FIXNUMS
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 22 Jul 88 19:08:37 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa06384; 22 Jul 88 19:23 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 22 Jul 88 19:19:28 BST
Message-Id: <23965.8807221819@aiai.ed.ac.uk>
To: jeff <@NSS.Cs.Ucl.AC.UK:jeff@aiai.edinburgh.ac.uk>,
sandra <@cs.utah.edu:sandra@cdr>
Subject: Re: more on BOGUS-FIXNUMS
Cc: cl-cleanup@sail.stanford.edu
> From: sandra <(Sandra J Loosemore)sandra%cdr@edu.utah.cs>
> Date: Fri, 22 Jul 88 10:56:40 MDT
> I think this is probably just a misunderstanding of terminology --
> what Stan Shebs described to me as being "fixnums" are clearly not the
> same beasties that you call "fixnums".
Yes, but the advantage of my position is that the beasties I call
"fixnums" are the same beasties Franz, MacLisp, and most CL's call
"fixnums". (So there.)
> I could play devil's advocate here and point out that the confusion
> over terminology tends to support my argument for getting rid of the
> name "fixnum" from the language entirely;
No, it supports clarification of the terminology, not its elimination.
> when an implementation has several different classes of numbers,
> which one(s) do you call "fixnum"?
The ones that are like "ints" (or maybe "longs"): that is, the ones
that are like machine integers (modulo type tags). Of course, we
already know an implementation might pick a losing implementation of
fixnums, but there are lots of ways a CL can lose and still be CL.
> In PSL and its derivatives, for example, the class of
> numbers which are called "inums" (represented as immediate data) are
> more "fixnum"ish than the class of numbers called "fixnums"!
Actually (looking at PSL documentation), I suppose either could be
called fixnums if PSL were a Common Lisp; but PSL's "fixnums" are
closer to what I mean by "fixnums", espectially where inums are 19 bit
and fixnums are 36 (DEC-20).
What I want from fixnums is that proper declarations will get me
compiled code not much less efficient than for other languages on
the same machine, and using numbers with similar range. (I'm willing
to allow type information and for fixnums to be immediate.)
Perhaps we should add somethng to CL for integers are are represented
immediately. In some implementations, this would be the same set as
fixnums, but would not have to be.
BTW, my "real" address is below.
Cheers,
Jeff
Jeff Dalton, JANET: J.Dalton@uk.ac.ed
AI Applications Institute, ARPA: J.Dalton%uk.ac.ed@nss.cs.ucl.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
∂23-Jul-88 0838 CL-Cleanup-mailer Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Jul 88 08:38:37 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA22032; Sat, 23 Jul 88 09:38:12 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA02390; Fri, 22 Jul 88 10:58:36 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807221658.AA02390@cdr.utah.edu>
Date: Fri, 22 Jul 88 10:58:35 MDT
Subject: Re: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 27 Jun 88 15:37 EDT
This seems like a good idea to me. We here at Utah ran into the same
problem with our implementation of pathnames for Unix PCLS.
-Sandra
-------
∂24-Jul-88 2306 CL-Cleanup-mailer Re: [Masinter.pa: Re: questions]
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 24 Jul 88 23:06:41 PDT
Received: from csilvax by hub.ucsb.edu (5.59) id AA25226; Sun, 24 Jul 88 10:03:24 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA16752; Sun, 24 Jul 88 09:57:24 PDT
Date: Sun, 24 Jul 88 09:57:24 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Sun, 24 Jul 88 09:57:24 PDT
To: CL-CLEANUP@SAIL.STANFORD.EDU
Subject: Re: [Masinter.pa: Re: questions]
Cc: chapman@hudson.dec.com
This is a response to the first part of the first of Kathy's questions:
My impression is that the return value of close is at most nil, rather than
the stream. Actually I've assumed that it returns no values, since none were
mentioned and none were that useful.
This impression seems to be shared by at least some other authors. I've
checked a few implementations (KCL retuns t) and several textbooks (most don't
mention it, apparently deliberately, but Wilensky says he's assuming it returns
nil and Brooks' example indicates that no value is returned).
On the other hand, perhaps the lack of a return value in CLtL is just a printing
error. (After all, I didn't assume that make-array returns no values!). Is it
perhaps the case that all of the built-in functions have at least 1 return
value?
Skona
∂25-Jul-88 0716 CL-Cleanup-mailer Re: [Masinter.pa: Re: questions]
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 25 Jul 88 07:16:46 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 25 Jul 88 10:14:44 EDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: CL-CLEANUP@SAIL.STANFORD.EDU, chapman@hudson.dec.com
Subject: Re: [Masinter.pa: Re: questions]
In-reply-to: Your message of Sun, 24 Jul 88 09:57:24 -0700.
Date: Mon, 25 Jul 88 10:14:23 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I think that our working assumption has always been that, if no return
value is mentioned, NIL is returned as a single value unless there's
something obvious that has to come back as in MAKE-ARRAY. Returning no
values is more expensive than returning NIL and discarding it in many
implementations, since the single-return case usually is special-cased for
maximum speed.
-- Scott
∂26-Jul-88 1656 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88 16:56:39 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08760; Tue, 26 Jul 88 16:56:26 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA00842; Tue, 26 Jul 88 16:50:21 PDT
Date: Tue, 26 Jul 88 16:50:21 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:50:21 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Cc: SKONA@csilvax.ucsb
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Revision 2 by Skona Brittain 07/26/88 (incorp.June discussion)
Problem Description:
The case of two slots of a structure having string-equal names, which
is obviously fraught with ambiguity, is not discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have string-equal names.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
Test Cases:
(I) (III)
(defstruct struc (defstruct struc1
slot slot)
slot) (defstruct (struc2 (:include struc1))
slot)
(II) (IV)
(in-package 'foo) (in-package 'foo)
(defstruct struct (defstruct foo-struct
slot1 slot1)
bar:slot1) (in-package 'bar)
(defstruct (bar-struct (:include foo:foo-struct))
slot1)
Rationale:
Since it would be difficult to prescribe (or even imagine) reasonable
behavior for this situation, it should be considered an error.
Current Practice:
Sun Common Lisp 2.0.3 detects attempts to define structures with string-equal
slots at defstruct expansion time, even if the conflicting slot comes from
inheritance.
Symbolics Common Lisp in Genera 7.2 and Kyoto Common Lisp June 3, 1987
don't notice the conflict and different kinds of haphazard behavior ensue.
At least in KCL, the details differ between the various test cases above.
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Kent thinks this proposal should be strengthened, either by specifying
a particular odd behavior to ensue or, preferably, by requiring the error
to be signaled (or perhaps even signalled).
Skona thinks that is too strong. This error is on par with many others
in CL that need not be signaled (such as defining a function with
string-equal argument names). The cost of the checking does not seem worth it.
Barry suggests that we facilitate including a structure defined in
a different package without worrying about string-equal names
by allowing non-keyword symbols to be used as slot name "keywords"
(i.e. as keyword arguments to the constructor/accessor functions)
as in the extension to keyword argument syntax that was done for CLOS.
(If this proposal is thusly modified, we should also add a requirement
to the default printed representation of structures that the slot names
get printed with their package prefixes. Maybe something should be said
anyway to standardize whether the slot names or the associated keyword
symbols are printed.)
Larry thinks that that alternative is going in the wrong direction: rather
than enhance defstructure, we should let it do the simple stuff efficiently
and have CLOS provide the extra power & flexibility when necessary.
∂26-Jul-88 1657 CL-Cleanup-mailer ISSUE: DEFSTRUCT-REDEFINITION
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88 16:57:42 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08778; Tue, 26 Jul 88 16:57:41 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA00851; Tue, 26 Jul 88 16:51:37 PDT
Date: Tue, 26 Jul 88 16:51:37 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:51:37 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: DEFSTRUCT-REDEFINITION
Cc: SKONA@csilvax.ucsb
Issue: DEFSTRUCT-REDEFINITION
References:
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 07/26/88
Problem Description:
The case of a structure type being redefined is not discussed in CLtL.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-ITSELF):
It is an error to redefine a structure.
Proposal (DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE):
Redefining a structure is ok but it is an error to access, in any way,
an instance of the structure that was created prior to the redefinition.
This applies to instances of other structures that :INCLUDEd the
redefined structure.
It is also an error to use any of the redefined structures accessors
on any instances of a structure that :INCLUDEd the previous definition.
Test Cases:
(I)
(defstruct struc1
slot1 slot2)
(setq s (make-struc1 :slot1 1 :slot2 2))
(defstruct struc1 ; this is an error according to ERROR-BY-ITSELF
slot2 slot1) ; but not according to ERROR-IFF-USE
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
(II)
(defstruct struc1
slot1 slot2)
(defstruct (struc2 (:include struc1))
slot 3)
(defstruct struc1
slot2 slot1)
(setq s (make-struc2 :slot1 1 :slot2 2))
(struc1-slot1 s) ; this is an error according to ERROR-IFF-USE
Rationale:
The issue of redefinition should be addressed since there are always
consequences that affect use of the structures: at the very least,
the constructor function gets overwritten when a structure is redefined.
ERROR-BY-ITSELF is simpler, but ERROR-IFF-USED is more amenable to use.
Current Practice:
None of KCL, Lucid, & Symbolics detect a redefinition, but all of them
return 2 as the value of the last forms in each of the above test case sets.
Cost to Implementors:
ERROR-ITSELF: none if not signaled. extremely slight if signaled.
ERROR-IFF-OLD-USE: none if not signaled. much more if signaled.
Cost to Users:
ERROR-ITSELF: It can be quite inconvenient to be prevented from "correcting"
a structure definition, which would presumably happen if the error were
signaled.
ERROR-IFF-OLD-USE: None.
Cost of Non-Adoption:
Confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Larry supports ERROR-BY-ITSELF, "in that slot-accessors for structures are
presumed to be declared "inline". If users want more flexibility than that,
they should use defclass."
Various inbetween proposals are possible, such as only incompatible
redefinitions cause errors, but they're too hard to define.
My feeling is that it's a cop-out to just say it's an error to redefine
a structure but then never signal the error - users will still be confused
by the differing seemingly erratic behavior and code.
∂26-Jul-88 1658 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88 16:58:36 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08804; Tue, 26 Jul 88 16:58:34 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA00859; Tue, 26 Jul 88 16:52:33 PDT
Date: Tue, 26 Jul 88 16:52:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:52:33 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
Cc: skona@csilvax.ucsb
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: CHANGE
Edit history: Revision 1 by Skona Brittain 07/26/88
Problem Description:
The symtax of items in the variable-list for various control structues
(do, let, prog and their duals) varies. This variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
Note that just plain var is prohibited in do forms
and that the case of (var) is prohibited in let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
Rationale:
The assymetry is unnecessary and impedes learning of CL.
Current Practice:
KCL allows (var) in let
but not var in do.
Cost to Implementors:
Very slight.
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than assymetry, at least to some of us.
Discussion:
∂26-Jul-88 1659 CL-Cleanup-mailer A lambda question
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 26 Jul 88 16:59:17 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA08824; Tue, 26 Jul 88 16:59:21 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA00866; Tue, 26 Jul 88 16:53:21 PDT
Date: Tue, 26 Jul 88 16:53:21 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Tue, 26 Jul 88 16:53:21 PDT
To: cl-cleanup@SAIL.Stanford.edu
Subject: A lambda question
Cc: skona@csilvax.ucsb
Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?
If not, does anybody want such a proposal? I recall
someone (Barry or Richard I think) mentioning it in
Boston but I don't remember what the reaction was or
if there even was any.
If there were to be such a function, what would be a
good name for it?
Skona
∂26-Jul-88 1725 CL-Cleanup-mailer Re: A lambda question
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 26 Jul 88 17:25:40 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 26 Jul 88 20:22:05 EDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.Stanford.edu, skona@csilvax.ucsb
Subject: Re: A lambda question
In-reply-to: Your message of Tue, 26 Jul 88 16:53:21 -0700.
Date: Tue, 26 Jul 88 20:20:57 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ? I assume that the proposal will
allow this function to return NIL if the original lambda expression has
been compiled or optimized to the point where it can no longer be
retrieved? I wouldn't want to require memory-tight implementations to keep
around the original form in all cases.
-- Scott
∂28-Jul-88 1201 CL-Cleanup-mailer Issue BOGUS-FIXNUMS (Version 2)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 28 Jul 88 12:01:26 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA06896; Thu, 28 Jul 88 13:00:51 MDT
Received: by cdr.utah.edu (5.54/utah-2.0-leaf)
id AA05586; Thu, 28 Jul 88 13:00:48 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8807281900.AA05586@cdr.utah.edu>
Date: Thu, 28 Jul 88 13:00:46 MDT
Subject: Issue BOGUS-FIXNUMS (Version 2)
To: cl-cleanup@sail.stanford.edu
Issue: BOGUS-FIXNUMS
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 11 Jul 1988, Sandra Loosemore
Version 2, 27 Jul 1988, Sandra Loosemore (change direction)
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
Furthermore, it is conceivable that an implementation could support
only a single internal representation for integers, and some
implementations do support more than two representations with varying
ranges and degrees of "efficiency". In such a case, arbitrarily
partitioning integers into "fixnums" and "bignums" becomes an
artificial contrivance which is more likely to confuse users than to
ensure portability of code.
Proposal: BOGUS-FIXNUMS:TIGHTEN-DEFINITION
(1) Change the wording at the top of page 14 of CLtL:
In most Common Lisp implementations, there is a range of integers that
are represented or operated on more efficiently than others; each such
integer is called a FIXNUM. Common Lisp is designed to hide this
distinction as much as possible; the distinction between fixnums and
non-fixnums is visible to the user in only a few places where the
efficiency of representation or operation is important. Exactly which
integers are fixnums is implementation-dependent. However, it is
required that (SIGNED-BYTE 16) be a subtype of FIXNUM in every
implementation of Common Lisp. If an implementation does not provide
a distinguished representation for small integers in this range, then
the types INTEGER and FIXNUM are considered equivalent in that
implementation. See MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM.
(2) Change the wording at the top of page 34 of CLtL to indicate that
FIXNUM is a subtype of INTEGER (removing the reference to BIGNUM).
(3) Remove BIGNUM from the table of standard type specifier symbols on
page 43 of CLtL.
(4) State that the constants MOST-POSITIVE-FIXNUM and
MOST-NEGATIVE-FIXNUM are allowed to have a value of NIL to indicate
that the implementation does not have a particular FIXNUM
representation distinct from other integers.
(5) Introduce a new constant, MAX-INTEGER-LENGTH. This is the maximum
number of bits appearing in any integer; therefore, it is an upper
bound on the INTEGER-LENGTH function. The value can be NIL if there
are no limits short of memory availability.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable, and allows programmers to use the
FIXNUM type specifier in a way similar to how the "int" type is used
in C.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. I know of no other Lisp which
claims to be an implementation or subset of Common Lisp that has
fixnums less than 24 bits long.
Several existing Lisps have more than two representations for
integers, including Lisp 1.6 and Portable Standard Lisp. The only
Lisps that exist now that have a single integer representation appear
to be subsets that do not support infinite-precision arithmetic (for
example, XLisp and A-Lisp).
A number of implementations place constraints on the size of integers
apart from memory availability. For example, the maximum number of
bits may be constrained to fit in a fixed-length field.
Cost to implementors:
Slight. All implementations I know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
(or document it as an extension to the language) to be in compliance
with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used. Code which assumes that the values of
the constants MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM are fixnums
would have to be changed to allow for the fact that they might be NIL.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
Introducing a new constant to describe the maximum size of integers makes
it possible to describe an implementation's exact limitations on the range
of integers it supports. This constant would also be useful for the
description of subset implementations.
Discussion:
An earlier proposal on this issue to remove the FIXNUM type specifier
entirely was almost universally hated.
Masinter and Fahlman expressed agreement with the general direction of
the current proposal. Pitman would like to see the range of FIXNUMs
remain undefined and a SMALL-INTEGER type with a fixed range (but no
promises about efficiency) introduced. JonL would like to see a
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing on stock hardware).
Dalton suggests that the FIXNUM type should be made analagous to the
"int" type in C. While the original K&R definition of C didn't
guarantee anything about integer sizes, the ANSI C standard requires
ints to be at least 16 bits long.
Addition of the MAX-INTEGER-LENGTH constant was suggested by Stan Shebs.
-------
∂28-Jul-88 1917 CL-Cleanup-mailer MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88 19:17:42 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 28 Jul 88 22:16:20 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 28 Jul 88 22:13:59 EDT
Date: Thu, 28 Jul 88 22:15 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: MULTIPLE-VALUE-SETQ and SYMBOL-MACROLET interaction
To: cl-cleanup@sail.stanford.edu
Message-Id: <19880729021542.8.BARMAR@OCCAM.THINK.COM>
In CLOS, the way to access slots as if they were lexical variables is to
use WITH-SLOTS, which uses SYMBOL-MACROLET to macroexpand occurrences of
the slot names into (SLOT-VALUE <object> '<name>) forms. It also
converts any SETQ special forms into SETF forms.
But what about MULTIPLE-VALUE-SETQ? If SETQ is allowed to assign slot
variables then so should MULTIPLE-VALUE-SETQ. At first I thought this
would require a MULTIPLE-VALUE-SETF, and perhaps that is the right way
to go anyway. However, it could also be done by expanding the
requirement on SYMBOL-MACROLET: it could transform
(multiple-value-setq (<slot> ...) ...)
into
(progn (multiple-value-setq (#:GENSYM ...) ...)
(setf (slot-value <object> '<slot>) #:GENSYM))
This works properly in Symbolics Flavors because
(multiple-value-setq (var1 var2) <form>)
macroexpands into
(multiple-value-call #'(lambda (#:g1 #:g2) (setq var1 #:g1 var2 #:g2)) <form>)
which reduces it to a solved problem. Perhaps the CLOS committee was
assuming that MULTIPLE-VALUE-SETQ includes SETQ's in its expansion, but
this is not actually specified by CLtL.
barmar
∂28-Jul-88 2109 CL-Cleanup-mailer Re: Issue BOGUS-FIXNUMS (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88 21:09:35 PDT
Received: from Burger.ms by ArpaGateway.ms ; 28 JUL 88 21:08:41 PDT
From: masinter.pa@Xerox.COM
Date: 28 Jul 88 21:07:35 PDT
Subject: Re: Issue BOGUS-FIXNUMS (Version 2)
In-reply-to: sandra%cdr@cs.utah.edu's message of Thu, 28 Jul 88 13:00:46 MDT,
<8807281900.AA05586@cdr.utah.edu>
To: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880728-210841-4619@Xerox>
I'm sorry I didn't do this sooner, but I think the issue name should be
FIXNUM-NONPORTABLE instead of BOGUS-FIXNUMS. It is less emotionally loaded, and
follows the convention that issue names start with terms that can be found in
CLtI (Common Lisp the Index.) I'm not sure if "Bogus" is there, but I doubt that
the index entry would lead you to FIXNUMs if it were.
∂28-Jul-88 2200 CL-Cleanup-mailer Re: ISSUE: DEFSTRUCT-REDEFINITION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Jul 88 22:00:31 PDT
Received: from Burger.ms by ArpaGateway.ms ; 28 JUL 88 21:59:13 PDT
From: masinter.pa@Xerox.COM
Date: 28 Jul 88 21:58:08 PDT
Subject: Re: ISSUE: DEFSTRUCT-REDEFINITION
In-reply-to: skona%csilvax@hub.ucsb.edu's message of Tue, 26 Jul 88 16:51:37 PDT
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.Stanford.edu
Message-ID: <880728-215913-4668@Xerox>
Portable programs should not dynamically redefine structures.
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of the
language standard to define those interactions, except to note that they are not
portable.
I don't think it is a cop-out. I certainly don't want an error to be signalled.
I'm lacking a good terminology for describing the "is an error" situation that I
think this should be.
∂29-Jul-88 0803 CL-Cleanup-mailer Re: ISSUE: DEFSTRUCT-REDEFINITION
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 29 Jul 88 08:03:23 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA21344; Fri, 29 Jul 88 11:01:14 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA05303; Fri, 29 Jul 88 11:05:02 EDT
Message-Id: <8807291505.AA05303@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%SAIL.Stanford.edu@multimax
Subject: Re: ISSUE: DEFSTRUCT-REDEFINITION
In-Reply-To: Your message of 28 Jul 88 21:58:08 -0700.
Date: Fri, 29 Jul 88 11:04:58 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Programming environments are allowed, encouraged, etc. to allow such
redefinition, perhaps with warning messages. It is beyond the scope of
the language standard to define those interactions, except to note
that they are not portable. I don't think it is a cop-out. I
certainly don't want an error to be signalled. I'm lacking a good
terminology for describing the "is an error" situation that I think
this should be.
Why not "is non-portable"?
∂29-Jul-88 1410 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Jul 88 14:10:34 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03546; Fri, 29 Jul 88 14:09:49 PDT
Date: Fri, 29 Jul 88 14:09:49 PDT
Message-Id: <8807292109.AA03546@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: SYMBOL-MACROLET-SEMANTICS
Status: For Internal Discussion
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
Problem Description:
The SYMBOL-MACROLET construct introduced with CLOS in X3J13 document
88-002R, because it is specified as a macro, cannot make use of the
&environment argument mechanism to communicate with complex macros
appearing within its body. As a consequence, the behavior of
SYMBOL-MACROLET, when used in conjunction with side-effects and complex
macros, is inconsistent with that of MACROLET, and confusing to users.
Test Case:
(let ((a (make-array 5))
(i 0))
(macrolet ((place () `(aref a (incf i))))
(push x (place)))
i) ==> 1
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:FLUSH):
Remove SYMBOL-MACROLET from 88-002R. Remove WITH-ACCESSORS and
WITH-SLOTS, or modify them to use ordinary macros.
Rationale:
For most uses of SYMBOL-MACROLET, ordinary MACROLET can provide equivalent
expressive/abstraction power. E.g.,
(symbol-macrolet ((slot1 (slot-value foo 'slot1)))
(incf slot1))
becomes
(macrolet ((slot1 () (slot-value foo 'slot1)))
(incf (slot1)))
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion, and that ``recursive'' symbol macros
are an error. Specify that it is an error to try to SETQ a symbol macro.
Rationale:
The current specification of SYMBOL-MACROLET as a macro leads to
undesirable results if forms which produce side-effects are part of the
expansion of a symbol macro.
This potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Finally, the rule that SETQ of a symbol macro must be treated as a SETF of
the expansion seems to be a kludge which was introduced only to support a
code-walking version of SYMBOL-MACROLET. If SYMBOL-MACROLET were changed
to be a special form, this rule would no longer be needed, and should be
eliminated in order to make the distinction between symbol macros and
variables cleaner.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is removed from the language, no one will bear any cost
of implementation.
If it is modified to be a special form, compilers and interpreters will
have to change, as well as MACROEXPAND, MACROEXPAND-1, and SETF (at
least).
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
If SYMBOL-MACROLET is removed from the language, users will have to make
do with MACROLET. Users will be unable to overload names which already
have definitions as functions. E.g.,
(defclass foo () (car cdr))
(defun describe-foo (foo)
(macrolet ((car () (slot-value foo 'car))
(cdr () (slot-value foo 'cdr)))
...
Can't use normal car and cdr in here
...))
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:FLUSH reduces the implementation and maintenance
costs for a Common Lisp implementation. It also simplifies the language
by eliminating the concept of a "symbol macro."
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
There seem to be mixed feelings as to the desirability of SYMBOL-MACROLET
as a construct in the language. Some feel it hairs up the language while
offering only trivial benefit beyond what is already provided through
normal macros. Others herald it as a important new language feature.
If symbol macros are retained but SYMBOL-MACROLET made to be a special
form, aesthetics are improved by making symbol macros consistent with
normal macros.
Discussion:
As it was adopted by X3J13 as part of CLOS, there has been no formal
discussion on the pros and cons of SYMBOL-MACROLET on its own.
In favor of SYMBOL-MACROLET are the following arguments:
* It allows access to a different namespace for defining macros. That is,
it allows macros to be defined in the namespace previously used only by
variables. This can avoid name conflicts in certain situations.
* Certain "embedded languages" may be more easily implemented if
SYMBOL-MACROLET is available.
Arguments against SYMBOL-MACROLET include:
* It makes variable references opaque. That is, a symbol appearing as a
form is no longer necessarily a variable. Programs become correspondingly
more difficult to read and understand.
* There are other solutions to the problems of name collisions which
don't add this complexity to the language. Specifying prefixes for
WITH-SLOTS and WITH-ACCESSORS in the manner of DEFSTRUCT, for example,
would eliminate accidental name conflicts in practice.
* Symbol macros cannot accept arguments, and therefore cannot be used to
solve the name conflict problems in situations where macro arguments are
required.
∂29-Jul-88 2306 CL-Cleanup-mailer bignums
Received: from ucbvax.berkeley.edu by SAIL.Stanford.EDU with TCP; 29 Jul 88 23:06:49 PDT
Received: by ucbvax.berkeley.edu (5.59/1.28)
id AA15744; Fri, 29 Jul 88 23:03:47 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA26084; Fri, 29 Jul 88 19:07:48 PDT
Date: Fri, 29 Jul 88 19:07:48 PDT
Message-Id: <8807300207.AA26084@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: bignums
I'm disappointed if implementations without bignums are considered to be in
compliance with the specification of Common Lisp. The term "bignum" really
does have a meaning: integers whose range is limited only by available memory
and that lie outside of the fixnum range. If implementations have "bignums"
that are limited to a bit field length, then they don't really have bignums.
The term "bignum" typically implies other pieces of info about the integers
that it labels: bignums cons and arithmetic on them is not as efficient as
that performed on fixnums.
While I applaud the effort to provide truely portable type specifiers, I do
not agree with the sentiment for removing from Common Lisp type specifications
that are not portably defined in so far as the range of values contained in
the type varies from implementation to implementation. The type of programming
that you do when you use "fixnums" is very different from what you do using
a specific integer range. Retaining the term "bignum" to denote that type of
integers that I described above, even as varying from implementation to
implementation seems useful to me. Sometimes, you want to program in a
mostly portable way that takes into account the underlying system for sake
of efficiency. I see no reason why the type specifiers "fixnum" and even
"bignum" are not useful identifiers for often-used concepts in this sort of
programming. So, I advocate leaving "fixnum" and "bignum" as type identifiers
in Common Lisp. I'd also advocate further specifying that "bignums" really
should have range limited only my memory space and that using a fixed bit-field
size is NOT an appropriate implementation of "bignums".
--Joe Ginder
∂31-Jul-88 1340 CL-Cleanup-mailer Issue BOGUS-FIXNUMS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 31 Jul 88 13:40:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440629; Sun 31-Jul-88 16:39:34 EDT
Date: Sun, 31 Jul 88 16:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue BOGUS-FIXNUMS (Version 2)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807281900.AA05586@cdr.utah.edu>
Message-ID: <19880731203905.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve of BOGUS-FIXNUMS:TIGHTEN-DEFINITION for the most part, but
I have a few comments and doubts to offer.
(3) Remove BIGNUM from the table of standard type specifier symbols on
page 43 of CLtL.
I don't approve or disapprove of this part; I'm of two minds about it. It
may be an unnecessary incompatible change. If anyone opposes it, I will
go along with them.
(4) State that the constants MOST-POSITIVE-FIXNUM and
MOST-NEGATIVE-FIXNUM are allowed to have a value of NIL to indicate
that the implementation does not have a particular FIXNUM
representation distinct from other integers.
I don't think that allowing these constants to be NIL enhances portability.
That means a lot of "gratuitous" checking for NIL would be required. I
think a better idea is to require that these constants always have integer
values, and that if an implementation really cannot identify any efficient
range of integers, it should set these constants to arbitrary values
consistent with the requirement that (SIGNED-BYTE 16) is a subtype of
FIXNUM. Think about a program that would use these constants to
parameterize an algorithm, as in the example taken from Macsyma that does
modular arithmetic using the largest prime modulus that fits in a FIXNUM.
What does such a program gain by allowing NIL here?
In fact I would think that an implementation with only one representation
for integers could define integers represented in a single bignum-digit to
be its fixnums; those are more efficient than larger integers, just not by
as large a factor as in some other implementations.
(5) Introduce a new constant, MAX-INTEGER-LENGTH. This is the maximum
number of bits appearing in any integer; therefore, it is an upper
bound on the INTEGER-LENGTH function. The value can be NIL if there
are no limits short of memory availability.
Again I don't think allowing this constant to be NIL makes sense. You
surely aren't saying that if this constant is non-NIL, the implementation
guarantees that there is enough memory to create at least one integer of
the specified length, let alone as many integers of that length as the
program might need. Thus memory availability is always a limitation, and
implementations that truly have no representation limit on the number of
bits in an integer should set this constant to a value that is guaranteed
to be higher than the memory limit.
Possibly what I just said is an argument that this constant should not exist,
because there is no correct way to use it. It tells a portable program
nothing about what it can or cannot do.
Or possibly it's an argument that under your definition, any implementation
with a non-NIL MAX-INTEGER-LENGTH would be in violation of the bottom of
CLtL page 13, which says there is no limit on the magnitude of an integer
other than storage. By that reasoning the Symbolics 3600 would be in
violation, since its address space exceeds its bignum representation limit.
However, the bignum representation limit is large enough that numbers of
that size become impracticably slow [see, memory isn't the limit either,
the real limit can be asymptotic speed of arithmetic algorithms] and I
doubt that Symbolics would care to change their bignum representation
to allow larger bignums which no one could actually use.
Introducing a new constant to describe the maximum size of integers makes
it possible to describe an implementation's exact limitations on the range
of integers it supports. This constant would also be useful for the
description of subset implementations.
It's true that it's useful to describe these aspects of an implementation.
I'm not sure that that justifies putting the description into the Common
Lisp language, rather than English. On the whole, I weakly oppose part 5.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable, and allows programmers to use the
FIXNUM type specifier in a way similar to how the "int" type is used
in C.
I.e. as an unending source of bugs and portability problems. :-(
Maybe I'm just down on C today.
∂01-Aug-88 0716 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88 07:16:35 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440735; Mon 1-Aug-88 10:16:17 EDT
Date: Mon, 1 Aug 88 10:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY (Version 1)
To: skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 26 Jul 88 19:52 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801101542.3.KMP@PEWEE.SCRC.Symbolics.COM>
I'm happy to see this issue raised. This stupid little inconsistency
has been irritating me and others for a while now.
However, I recommend re-casting the proposal to permit all three forms.
The rationale for that is:
- Most implementations provide all three versions since Maclisp
did. In cases where there is a pre-CL tradition, that's usually
the winner.
- Regularization is nice, but some may find it gratuitous. To
minimize code breakage, the right thing is to only add cases,
not remove any, if that is feasible. In this case, it is
trivially possible. Simply add ``(VAR)'' for DO and DO*
and ``VAR'' for LET/LET*.
Btw, in Current Practice, Symbolics Genera permits all three forms.
∂01-Aug-88 0742 CL-Cleanup-mailer A lambda question
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88 07:42:41 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440759; Mon 1-Aug-88 10:41:05 EDT
Date: Mon, 1 Aug 88 10:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A lambda question
To: Scott.Fahlman@B.GP.CS.CMU.EDU, skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 26 Jul 88 20:20 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
The message of 26 Jul 88 16:53 PDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801104035.4.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Tue, 26 Jul 88 20:20:57 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
If there were to be such a function, what would be a
good name for it?
How about EXTRACT-LAMBDA-EXPRESSION ?
The T language provides such a primitive. It is called DISCLOSE
(named for symmetry with the ENCLOSE primitive which occurs in some
Scheme dialects and coerces a lambda expression into a procedure).
DISCLOSE may be overly generic-sounding for CL use, but I recommend
DISCLOSE-DEFINITION.
I assume that the proposal will allow this function to return NIL if
the original lambda expression has been compiled or optimized to the
point where it can no longer be retrieved? I wouldn't want to require
memory-tight implementations to keep around the original form in all
cases.
Since some applications for DISCLOSE have semantic impact, I don't agree
that it should be possible for an implementation to simply throw away
the information. I believe that we should spell out particular cases
in which it is or is not permissible. My personal preferences follow:
- No compiler should be required to retain the source code
when using the file compiler. That is, using COMPILE-FILE
does not make the definition available in the environment into
which the definitions are subsequently LOADed.
- I am agnostic about interactive DEFUN, etc. I am content to see
this information retained only at the discretion of the
interpreter.
- I would prefer that arguments to COMPILE be retained, and possibly
defuns done by explicit EVAL as well. The reason for this is that
programs like Macsyma which have need of this function do not just
go around peeking into arbitrary functions (in my experience). They
usually want to peek into functions that they themselves instantiated.
So primitives that allow explicit runtime instantiation of functions
on a case-by-case basis should be reliably invertible (in my opinion).
Notes:
- I would be ammenable to permitting this function to be SETF-able,
so that people could ``NIL out'' definitions they didn't want to
retain.
- I would also be ammenable to having a special argument to COMPILE
saying that the information must be retained. I don't care what
the default value was.
- If there is not any reliable situation in which a definition will
have this information retained, then all the uses I have ever had
for this except for pretty printing are nullified. Perhaps the
pretty printing argument is reason enough to have it, though.
- There is some question about whether in the case of named objects,
(DEFUN FOO (X) X)
(DISCLOSE-DEFINITION #'FOO) => (LAMBDA (X) X) or (DEFUN FOO (X) X)?
I think the latter.
Does whether FOO is still fdefined matter? I think not.
∂01-Aug-88 1024 CL-Cleanup-mailer A lambda question (a.k.a. issue FUNCTION-DEFINITION)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88 10:24:22 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440856; Mon 1-Aug-88 13:23:04 EDT
Date: Mon, 1 Aug 88 13:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: A lambda question (a.k.a. issue FUNCTION-DEFINITION)
To: Scott.Fahlman@B.GP.CS.CMU.EDU, skona%csilvax@hub.ucsb.edu
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <880801104035.4.KMP@PEWEE.SCRC.Symbolics.COM>,
The message of 26 Jul 88 20:20 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
The message of 26 Jul 88 16:53 PDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880801132228.0.KMP@PEWEE.SCRC.Symbolics.COM>
Actually, you faked me into thinking this wasn't written up.
In fact, I submitted a proposal on this a while back:
FUNCTION-DEFINITION, Version 1, Pitman, 23-Jun-88
Much of my previous message was a re-hash of what had gone into
that proposal. If you don't have a copy and need one, send me
mail privately and I'll re-transmit it to you.
∂01-Aug-88 1041 CL-Cleanup-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Aug 88 10:41:34 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 AUG 88 10:26:21 PDT
Date: 1 Aug 88 10:26 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: cutting.pa@Xerox.COM
Message-ID: <880801-102621-1527@Xerox>
Issue: UNREAD-CHAR-AFTER-PEEK-CHAR
References: pp 379, 380 of CLtL
Category: CLARIFICATION
Edit history: Version 1 by Doug Cutting <Cutting.PA@Xerox.COM> on July 29, 1988
Problem description:
PEEK-CHAR and UNREAD-CHAR are very similar mechanisms. The description of
PEEK-CHAR in CLtL even states that "it is as if one had called READ-CHAR and
then UNREAD-CHAR in succession." But while CLtL prohibits calling UNREAD-CHAR
twice in succession it does not prohibit calling UNREAD-CHAR after PEEK-CHAR.
The obvious implementation of PEEK-CHAR and UNREAD-CHAR (a one-character buffer)
will not work unless this prohibition is present.
Proposal (UNREAD-CHAR-AFTER-PEEK-CHAR:DONT-ALLOW): UNREAD-CHAR may not be called
after PEEK-CHAR without an intervening call to READ-CHAR.
Test Cases/Examples:
;;; Following is an example of code which should not be valid CL.
(defun test (stream)
(let ((char (read-char stream)))
(peek-char nil stream)
(unread-char char stream)
(assert (eql char (read-char stream)))))
Rationale:
PEEK-CHAR and UNREAD-CHAR provide equivalent functionality and it is thus
reasonable for an implementation to implement them in terms of the same
mechanism.
Current practice:
In Xerox Common Lisp, different (non-random-access) stream types behave
differently. One, (TCP/FTP) handled this correctly, while another (keyboard with
line-buffering turned off) did not.
Cost to Implementors:
Zero. Implementations which allow this are still correct.
Cost to Users:
Small. I suspect there is very little code which depends upon this working
correctly, as most code uses either PEEK-CHAR or UNREAD-CHAR, but not both.
Cost of non-adoption:
Implementations of sequential streams are forced to be unnecessarily complex in
order to be correct.
Benefits:
Allows simple yet adequately powerful implementation of sequential streams.
Esthetics:
Requires that users have shared, one-char buffer model of how UNREAD-CHAR and
PEEK-CHAR work, rather than two separate one-char buffers.
Discussion:
∂01-Aug-88 1058 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88 10:58:48 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440873; Mon 1-Aug-88 13:57:53 EDT
Date: Mon, 1 Aug 88 13:57 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
To: piazza%lisp.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8807292109.AA03546@decwrl.dec.com>
Message-ID: <880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
I assume this is the SYMBOL-MACROLET-UTILITY issue in another guise,
though the edit history does not reflect that. Can we please just pick a
topic name and stick to it? I file these by topic and this kind of
mid-topic name shift (especially without clearly identifying the intent)
leaves me with two files, each containing half of the relevant mail.
Some comments on the writeup itself:
- I find the tone of the writeup to use a kind of bias that made it
hard to read. I'd be happier if the tone were more objective.
- Proposals should not talk about changing existing documents. 88-002R
is written, fixed, and basically cannot change. What you want to change
is the part of CL which was changed by its adoption. The convention in
cleanup proposals is to refer abstractly to changing the language, so
your proposal doesn't become obsolete as the names of reference documents
change.
- The problem description does not adequately describe the problem.
I suspect this is related to the tone problem, which feels like it's
emerging out of the heat of a debate to be read by someone involved
in that debate rather than that it's something intended to be read
cold by the X3J13 members not following this discussion. The latter
should be the target audience. It should be possible to read the problem
description out of context and know something interesting about CL, and
I don't think you can do that with this writeup.
We have generally used the Test Case section to describe the
proposal, not the problem, so the problem description should at
least explicitly allude to the test case as being critical to the
problem description. In fact, though, I think you need more expository
text to make it really obvious what the issue was. The first three times
I read the problem description, I thought you were just griping about
the absence of &ENVIRONMENT information going into SYMBOL-MACROLET.
- I think the stated issue is really orthogonal to the proposed solutions.
For example, flushing the feature because it has a problem is the trivial
solution to almost any problem, so it doesn't really show whether your
solution is going anywhere.
The Special Form solution -- even though I like the idea of it being a
special form -- is not a solution to the stated problem. It makes this be
a non-issue for system-supplied things that can inspect the environment
information, but you don't provide access to that information for user
programs.
In my mind, part of the solution must involve the introduction of a
SYMBOL-MACRO-FUNCTION function, which is like MACRO-FUNCTION but tells
you if something is a symbol macro. This might be implementable portably,
though it would certainly be easier if it were a special form.
- I observe that the change to MACROEXPAND and MACROEXPAND-1 is probably
desirable, but that this isn't the only way to do it. For example, you
could have a separate function for expanding symbol-macros, or you could
funcall SYMBOL-MACRO-FUNCTION of the symbol. Probably changing MACROEXPAND
will be the most natural way to deal with it, but I wanted to note this
flexibility for the record.
- I'm personally happy to see the FLUSH option removed and have this proposal
elaborated around the special form solution since I don't think it's going
to fly and I don't personally want to waste time on it. I guess if everyone
doesn't agree on that, though, it's gotta be retained for now, though.
∂01-Aug-88 1133 CL-Cleanup-mailer Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Aug 88 11:33:32 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 440902; Mon 1-Aug-88 14:33:05 EDT
Date: Mon, 1 Aug 88 14:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Cutting.PA@Xerox.COM
In-Reply-To: <880801-102621-1527@Xerox>
Message-ID: <880801143232.2.KMP@PEWEE.SCRC.Symbolics.COM>
This is a reasonable issue. I think I'll eventually buy into it, but let
me suggest some changes I'd like to see before I do.
- The proposal part is confusingly worded.
The wording says that in a stream "abc", if I READ-CHAR to get the #\a
into variable CH1 and then I PEEK-CHAR to see the "b", then I must call
READ-CHAR before I can (UNREAD-CHAR CH1). But if I take that literally,
I'll do (SETQ CH2 (READ-CHAR S)) (UNREAD-CHAR CH1 S) and that's not what
I want. Having done the READ-CHAR, I can only UNREAD-CHAR the char I just
did READ-CHAR to get. In effect, I can never UNREAD-CHAR CH1 once I've
peeked at or read the next char. Some streams will let me back up at this
point, but only those which would have let me back up before doing the
READ-CHAR in the first place.
It would be clearer for the proposal to just say that doing either a
PEEK-CHAR or READ-CHAR `commits' all previous characters. UNREAD-CHAR
on any character preceding that which is seen by the PEEK-CHAR (including
those passed over by PEEK-CHAR when `seeking' with a non-NIL first
argument) is not portable.
- A misreading of the proposal might lead one to believe that one could
do (SETQ CH1 (READ-CHAR STREAM))
(SETQ CH2 (PEEK-CHAR NIL STREAM))
(SETQ CH3 (READ-CHAR STREAM))
(UNREAD-CHAR CH1 STREAM)
since the unread-char is correctly separated from the PEEK-CHAR by an
intervening READ-CHAR. The problem is that the wrong char is being
unread. Some implementations support this, but it's definitely not
condoned by the description of UNREAD-CHAR on p379.
- I found the following test case to be more insightful:
(defun test (&optional (stream *standard-input*))
(let* ((char1a (read-char stream))
(char2a (peek-char nil stream))
(char1b (progn (unread-char char1a stream)
(read-char stream)))
(char2b (read-char stream)))
(list char1a char2a char1b char2b)))
- Current practice (for my test case above) in Symbolics Genera:
(test)ab
=> (#\a #\b #\a #\b)
(with-input-from-string (s "abc") (test s))
=> (#\a #\b #\a #\b)
(progn (with-open-file (s "foo.output" :direction :output)
(write-string "abc" s))
(with-open-file (s "foo.output" :direction :input)
(test s)))
Signals an error about unreading #\a when #\b was already unread.
∂01-Aug-88 2023 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
Received: from hub (ucsbcsl.ucsb.edu) by SAIL.Stanford.EDU with TCP; 1 Aug 88 20:22:54 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA14148; Mon, 1 Aug 88 20:22:23 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA14310; Mon, 1 Aug 88 20:15:41 PDT
Date: Mon, 1 Aug 88 20:15:41 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Mon, 1 Aug 88 20:15:41 PDT
To: kmp@stony-brook.scrc.symbolics.com
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
Cc: cl-cleanup@sail.stanford.edu
I don't see any difference between my proposal and
the modification to it that you are recommending.
∂02-Aug-88 0717 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Aug 88 07:17:22 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 441230; Tue 2-Aug-88 10:16:16 EDT
Date: Tue, 2 Aug 88 10:15 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
To: skona%csilvax@Hub.UCSB.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 1 Aug 88 23:15 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <880802101539.3.KMP@PEWEE.SCRC.Symbolics.COM>
Date: Mon, 1 Aug 88 20:15:41 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
I don't see any difference between my proposal and the
modification to it that you are recommending.
I'm not surprised. They're the same. :-}
Sorry. I guess I didn't read carefully enough.
But I'm pretty sure I knew what threw me off, and it might be worth
correcting the style. In the problem description, you enumerate the
cases without the use of [...]. Then later you introduce the brackets,
so I was looking for
var | (var) | (var val)
when you'd written
var | (var [val])
etc. You might want to consider one of the following syntactic tricks
to help keep others from falling into the same trap:
* Use notation such as the following in the problem description:
do & do*: (var [init [step]])
prog & prog*: var | (var [init])
let & let*: var | (var val)
so that it matches the proposal.
* Use notation such as the following in the proposal:
do & do*: var | (var) | (var init) | (var init step)
prog & prog*: var | (var) | (var init)
let & let*: var | (var) | (var init)
in the proposal so it matches the problem description.
* Say something in the running text of the proposal to make it clear
what's going on to people like me who don't read carefully enough.
eg,
``Extend the language to permit all of the following syntaxes:''
Also, the category for this change is wrong. It should be listed as an ADDITION,
not a CHANGE since it is not incompatible.
And while you're in there, I'd extend the rationale section to add the
comments I made in my last message. There are, after all, other ways you
could have gone with this proposal (such as the way I thought you were
proposing). When the rationale section can put concern about such
alternatives to rest, I think it should.
You can add my support of the proposal to the discussion section.
∂04-Aug-88 1522 CL-Cleanup-mailer ISSUE: VARIABLE-LIST-ASYMMETRY
Received: from hub (HUB.UCSB.EDU) by SAIL.Stanford.EDU with TCP; 4 Aug 88 15:22:38 PDT
Received: from csilvax.ucsb.edu by hub (5.59) id AA02242; Thu, 4 Aug 88 15:22:22 PDT
Received: from by csilvax.ucsb.CSNET (5.51) id AA24449; Thu, 4 Aug 88 15:15:33 PDT
Date: Thu, 4 Aug 88 15:15:33 PDT
From: Skona Brittain <skona%csilvax@hub.ucsb.edu>
Posted-Date: Thu, 4 Aug 88 15:15:33 PDT
To: cl-cleanup@sail.stanford.edu
Subject: ISSUE: VARIABLE-LIST-ASYMMETRY
Issue: VARIABLE-LIST-ASYMMETRY
References: CLtL pgs. 110, 122, 131
Category: ADDITION
Edit history: Revision 1 by Skona Brittain 07/26/88
Revision 2 by Skona Brittain 08/04/88 (change of category,
spelling & verbosity)
Problem Description:
The syntax of items in the variable-list for various control structues
(do, let, prog and their duals) varies. This variation seems unnecessary.
The allowed variations are indicated in the following chart:
do & do*: (var) (var init) (var init step)
prog & prog*: var (var) (var init) n.a.
let & let*: var (var val) n.a.
Note that just plain `` var '' is prohibited in do forms
and that the case of ``(var)'' is prohibited in let forms.
Proposal (VARIABLE-LIST-ASYMMETRY:SYMMETRIZE):
Allow all the variations in all of the forms;
i.e. add the prohibited cases mentioned above.
I.e. change the variable-list in the syntax descriptions as follows:
do & do*: ( { var | (var [init [step]] ) }* )
let & let*: ( { var | (var [value] ) }* )
Test Cases:
(let (a (b) (c 3)) ... ) would be valid.
(do* (a (b) (c 3)) ... ) would be valid.
Rationale:
The asymmetry is unnecessary and impedes learning of CL.
Any other way to make these cases consistent, such as either
omitting just ``var'' from do & do* and prog & prog*, or
omitting ``(var)'' from let & let* and prog & prog*,
would be an incompatible change to the language.
This way just adds the flexibility found in some of the forms to all of them.
Current Practice:
KCL allows ``(var)'' in let & let* but not ``var'' in do & do*.
Symbolics Genera allows all three cases in all the forms; i.e. it conforms
to this proposal.
Cost to Implementors:
Extremely slight. (May involve subtracting code rather than adding it).
Cost to Users:
None.
Cost of Non-Adoption:
The variation in syntax makes them harder to learn.
Benefits:
Ease of learning.
Aesthetics:
Symmetry is more aesthetic than asymmetry, at least to some of us.
Discussion:
Kent supports this proposal.
The issue about whether the atomic ``var'' should be allowed at all in the
variable lists for let & let* is a separate issue. (So is whether
it should mean that the var is initially bound to nil.) Since it is allowed,
this proposal merely says that the alternative syntax of an atom within a
list with no initial value, ``(var)'', should also be allowed.
∂04-Aug-88 1740 CL-Cleanup-mailer A lambda question
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Aug 88 17:39:48 PDT
Received: by labrea.stanford.edu; Thu, 4 Aug 88 17:38:30 PDT
Received: from bhopal.lucid.com by edsel id AA08863g; Thu, 4 Aug 88 17:35:17 PDT
Received: by bhopal id AA14409g; Thu, 4 Aug 88 17:37:05 PDT
Date: Thu, 4 Aug 88 17:37:05 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8808050037.AA14409@bhopal.lucid.com>
To: skona%csilvax@hub.ucsb.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Skona Brittain's message of Tue, 26 Jul 88 16:53:21 PDT <8807270025.AA26144@edsel.lucid.com>
Subject: A lambda question
re: Now that we've supposedly finished with function-type,
is anybody working on a proposal to introduce a func-
tion that would retrieve the lambda-expression defini-
tion from a user-defined function object?
Lucid Common Lisp has such a function, called SOURCE-CODE. It retrieves
the lambda expression used in an interpretive definition, even after sub-
sequent compilation of the function; but it does not attempt to maintain
an "out-of-core" database like the emacs TAGS facility.
-- JonL --
∂04-Aug-88 2349 CL-Cleanup-mailer bignums
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 4 Aug 88 23:49:47 PDT
Received: by labrea.stanford.edu; Thu, 4 Aug 88 23:48:34 PDT
Received: from bhopal.lucid.com by edsel id AA10028g; Thu, 4 Aug 88 22:30:50 PDT
Received: by bhopal id AA15094g; Thu, 4 Aug 88 22:32:30 PDT
Date: Thu, 4 Aug 88 22:32:30 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8808050532.AA15094@bhopal.lucid.com>
To: trwrb!smpvax1!jrg@ucbvax.berkeley.edu
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Fri, 29 Jul 88 19:07:48 PDT <8807300207.AA26084@trwrb.TRW.COM>
Subject: bignums
re: I'd also advocate further specifying that "bignums" really
should have range limited only my memory space and that using a fixed
bit-field size is NOT an appropriate implementation of "bignums".
Have you considered the possibility that for even moderately small
"fixed bit-field" sizes, the range of bignums specified is larger
than any reasonable amount of virtual memory that your operating
system will allow you to have (and garbage collect)?
Seriously, I have advocated a minimum size for most-positive-fixnum as
about 2↑24-1, which I think is defensible in terms of hardware to do
"efficient" arithmetic. Do you feel like proposing (and defending) a
minimum size for most-positive-bignum?
Two interesing stories (really true!):
(1) During the days that Bill Gosper was computing larger and larger
decimal expansions of pi, he happened upon a huge bignum on the 3600
that caused it to "die of constipation". It seems that sufficient
space had been allocated for it, but at the time of a GC flip, there
wasn't sufficient space to copy it. [This was about 1984 I think.]
(2) A similar thing actually happened to me later, on a 3600. Suspecting
that I knew about a "bit-field size", I was intending to compute
log2(most-positive-bignum); but unfortunately a typo put in some extra
shifting steps, so that I actually computed something close to
most-positive-bignum. As in RWG's case, I finally got caught by the
GC-flip, and fell into some sort of debugger loop. I intercepted it
a couple days later in a state of catatonia -- apparently it was trying
to print out the arguments in the frame that had caused the death, and
printing most-positive-bignum in base 10 appeared to be taking some time
. . .
-- JonL --
∂05-Aug-88 1006 CL-Cleanup-mailer issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 5 Aug 88 10:06:35 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA21471; Fri, 5 Aug 88 11:05:48 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA00261; Fri, 5 Aug 88 11:05:43 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8808051705.AA00261@defun.utah.edu>
Date: Fri, 5 Aug 88 11:05:42 MDT
Subject: issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
To: cl-cleanup@sail.stanford.edu
I hope this issue is minor enough to be noncontroversial.
-Sandra
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Current Practice:
Lucid Common Lisp implements the proposal. VaxLisp uses #S syntax
unless an explicit :PRINT-FUNCTION is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Perhaps some way of specifying that #S syntax should be used instead of
inheriting the print function of the parent type should be provided for
(such as specifying :PRINT-FUNCTION with no arguments).
-------
∂05-Aug-88 1024 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Aug 88 10:24:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 442651; Fri 5-Aug-88 13:23:51 EDT
Date: Fri, 5 Aug 88 13:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 1)
To: sandra%defun@cs.utah.edu
cc: Cl-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8808051705.AA00261@defun.utah.edu>
Message-ID: <880805132330.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Your writeup looks fine.
Non-preemptive comments:
* Under Rationale, you could mention that some implementations may be
using something like CLOS' DEFMETHOD to implement print-function,
and such methods will naturally be inherited. Your proposal is,
therefore, more consistent with a CLOS-oriented view of the world
than a non-inheriting proposal would be.
* Under Current Practice, both Symbolics Genera and Symbolics Cloe
implement your proposal.
* I support DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES.
* Discussion:
Perhaps some way of specifying that #S syntax should be used instead of
inheriting the print function of the parent type should be provided for
(such as specifying :PRINT-FUNCTION with no arguments).
Or naming the function that does what the #S printer does.
On the other hand, Waters has requested a function which would return
the #S information as a list (so he can pretty-print structures). The
same function could be used for this.
If the CLOS metaclass stuff goes in, this is presumably no longer needed.
∂16-Aug-88 1541 CL-Cleanup-mailer Issue: NTH-VALUE (Version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 16 Aug 88 15:41:38 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA06408; Tue, 16 Aug 88 18:41:35 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA06571; Tue, 16 Aug 88 18:43:14 EDT
Message-Id: <8808162243.AA06571@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: NTH-VALUE (Version 1)
Date: Tue, 16 Aug 88 18:43:11 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: Version 1 by Pierson 8/16/88
Status: For Internal Discussion
Problem description:
The set of actions on multiple values in Common Lisp is incomplete.
Proposal (NTH-VALUE:ADD):
Add a new macro:
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as a
single value. N is 0-based, i.e. the first returned value is value 0,
for compatability with NTH and NTHCDR.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This fills a hole in the initial definition of Common Lisp and permits
clearer code in some circumstances.
Current practice:
I don't know of any implementation that provides this feature.
Cost to Implementors:
A simple new macro needs to be written. In addition, most
implementations will choose to implement compiler hooks so that code
written with NTH-VALUE will be as efficient as possible.
Cost to Users:
None, this is an upward-compatible change.
Cost of non-Adoption:
This feature won't be available to portable programs.
Benefits:
This makes some code that uses multiple values easier to read and
write. In addition, it may be easier for implementations to optimize
expressions which use NTH-VALUE instead of using MULTIPLE-VALUE-BIND
and ignoring the unwanted values.
Aesthetics:
While it does add another function to the language it removes some
need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was rejected
then because it was too late in the cycle.
------- End of Forwarded Message
∂16-Aug-88 1627 CL-Cleanup-mailer Issue: NTH-VALUE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Aug 88 16:27:10 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 447350; Tue 16-Aug-88 19:25:26 EDT
Date: Tue, 16 Aug 88 19:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 1)
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8808162243.AA06571@mist.UUCP>
Message-ID: <880816192510.3.KMP@GRYPHON.SCRC.Symbolics.COM>
If I recall, I was originally talked down on the argument that I
shouldn't be thinking of values as an array-like vector to be
indexed into -- the argument being that this is not how arguments
to functions are treated. They, by contrast, are named.
However, in practice, I find that I often write things like:
(SIXTH (MULTIPLE-VALUE-LIST ...))
or
(NTH 5 (MULTIPLE-VALUE-LIST ...))
just for visual clarity and conciseness (in spite of the consing)
-- especially when picking apart hairy return values such as those
involved with the time functions, but also even in simpler cases.
A sufficiently clever compiler -could- just optimize my idiom,
I suppose, but still it would be nice to provide people with
something that was both efficient and perspicuous.
So, even though some people may have wished they could reform the way I
think about multiple values in some circumstances, the fact remains that
they didn't change my model. They only managed to make me feel
inconvenienced every time this comes up... So even after all this time,
I still think this is a good idea and generally support the idea of
this proposal.
However, I would like to see the wording tightened to make it clear that
the order of evaluation is left-to-right. "Evaluates N, then evaluates the
form...." or some such.
∂16-Aug-88 1641 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 16 Aug 88 16:41:03 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 16 Aug 88 19:39:17 EDT
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: NTH-VALUE (Version 1)
In-reply-to: Your message of Tue, 16 Aug 88 18:43:11 -0400.
<8808162243.AA06571@mist.UUCP>
Date: Tue, 16 Aug 88 19:39:05 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I'm not strongly opposed to this, but I've certainly never felt the need
for such a form. The cases where want only one value, but not the first
value, are so rare that I don't mind using the more verbose
multiple-value-bind idiom.
-- Scott
∂18-Aug-88 1114 CL-Cleanup-mailer (LET ((var)) ...) and (PROG ((var)) ...)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Aug 88 11:10:46 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Thu, 18 Aug 88 12:56:00 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 18 Aug 88 12:55:08 EDT
Date: Thu, 18 Aug 88 12:55 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: (LET ((var)) ...) and (PROG ((var)) ...)
To: cl-cleanup@sail.stanford.edu
Cc: mincy@Think.COM, massar@Think.COM
Message-Id: <19880818165506.0.BARMAR@OCCAM.THINK.COM>
There seems to be an inconsistency in CLtL regarding the syntax of the
variable lists in LET and PROG. On page 110 the syntax for LET is
given:
LET ( { var | (var value) }* ) ...
while on p.131 the syntax for PROG is
PROG ( {var | (var [init]) }* ) ...
This indicates that (PROG ((FOO)) ...) is allowed as a synonym for (PROG
((FOO NIL)) ...) and (PROG (FOO) ...). However, in the first paragraph
on p.132 it says that the PROG variable list "is processed exactly as
the list in a LET statement...."
Since the syntax descriptions aren't identical, they can't actually be
processed exactly the same.
Symbolics Common Lisp and KCL allow (var) in both LET and PROG. Sun CL
2.0.3 (on a Sun-3) gets an error for both (LET ((FOO))) and (PROG
((FOO))), and Sun CL 2.1.1 (on a Sun-4) and Lucid CL 2.1 give warnings
for LET but allow PROG silently.
Has this been addressed by any of the cleanup issues in the past? If
not, what's the right way to solve this?
barmar
∂18-Aug-88 1406 CL-Cleanup-mailer Issue VARIABLE-LIST-ASYMMETRY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Aug 88 14:06:30 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 448244; Thu 18-Aug-88 17:05:29 EDT
Date: Thu, 18 Aug 88 17:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue VARIABLE-LIST-ASYMMETRY
To: Barmar@Think.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, Mincy@Think.COM, Massar@Think.COM
In-Reply-To: <19880818165506.0.BARMAR@OCCAM.THINK.COM>
Message-ID: <880818170518.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
A cleanup item addressing this problem was created since the last meeting.
I think the issue name is VARIABLE-LIST-ASYMMETRY.
The proposal, which no one has objected to, is that PROG, LET, and DO --
which has its own inconsistency -- be upgraded to uniformly allow
{ var | (var [init ]) }* ; PROG, PROG*, LET, LET*
or { var | (var [init [step]]) }* ; DO, DO*
∂18-Aug-88 1631 CL-Cleanup-mailer Issue VARIABLE-LIST-ASYMMETRY
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 18 Aug 88 16:31:22 PDT
Received: by labrea.stanford.edu; Thu, 18 Aug 88 16:29:46 PDT
Received: from blacksox.lucid.com by edsel id AA08499g; Thu, 18 Aug 88 16:22:10 PDT
Received: by blacksox id AA01097g; Thu, 18 Aug 88 16:23:41 pdt
Date: Thu, 18 Aug 88 16:23:41 pdt
From: Eric Benson <edsel!eb@labrea.stanford.edu>
Message-Id: <8808182323.AA01097@blacksox.lucid.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: Barmar@think.com, CL-Cleanup@sail.stanford.edu, Mincy@think.com,
Massar@think.com
In-Reply-To: Kent M Pitman's message of Thu, 18 Aug 88 17:05 EDT <880818170518.1.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Subject: Issue VARIABLE-LIST-ASYMMETRY
Let's add COMPILER-LET to the first list.
∂21-Aug-88 1521 CL-Cleanup-mailer new item: RANGE-OF-COUNT-KEYWORD
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 21 Aug 88 15:20:43 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 21 Aug 88 18:18:08 EDT
To: cl-cleanup@sail.stanford.edu
cc: fahlman@cs.cmu.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: new item: RANGE-OF-COUNT-KEYWORD
Date: Sun, 21 Aug 88 18:18:00 EDT
Message-ID: <6305.588205080@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU
The Problem:
CLtL is overly vague about legal values for the :COUNT keyword. It says
that the keyword specifies "how many occurrences of the item should be
affected" (e.g., for REMOVE, it's the maximum number of items to remove).
If the value is NIL, it means "all occurrences". CLtL doesn't say
explicitly that the value of :COUNT must be an integer, nor does it say
what to do for negative values.
Current Practice:
CMU Common Lisp and KCL behave differently when given a negative fixnum
for the :COUNT keyword. CMU Common Lisp treats any value other than a
non-negative fixnum (e.g., values like -2, or 1.0) as if it were NIL. KCL
treats negative fixnums as equivalent to zero for lists, but does something
bizarre for vectors (it pads them with n blanks or NILs, where -n is the
value of the :count keyword keyword.)
Proposal RANGE-OF-COUNT-KEYWORD:RESTRICT-TO-INTEGERS
Add language to CLtL specifying that the only legal values for :COUNT
are integers and NIL.
Rationale:
Restricting :COUNT to integers most likely reflects CLtL's original
intent. Similar functions that accept numeric args, like NTH, explicitly
limit them to integers (CLtL, p. 265). The proposal simply makes this
explicit for the :COUNT keyword.
Proposal RANGE-OF-COUNT-KEYWORD:TREAT-NEGATIVE-LIKE-ZERO
Require functions that accept a :COUNT keyword to treat negative values
as equivalent to zero.
Rationale:
The proposed treatment of negative values is consistent with the current
wording of CLtL, which says (p. 253, for REMOVE) "if more than :count
elements satisfy the test, then of these elements only the leftmost are
removed, as many as specified by :count." Of course, you can't remove -3
items from a sequence, but for that matter you can't remove 3 items from a
sequence of length 2, either. It is implicitly understood that "as many
as" really means "no more than" as far as :COUNT is concerned.
The proposal also has the advantage of freeing the user from having to do
an explicit check for negative numbers when the value of :COUNT is computed
by some complex expression. Example:
(defun leave-at-most (n item sequence &key (from-end t))
(remove item sequence
:count (- (count item sequence) n)
:from-end from-end))
(leave-at-most 2 #\a "bananas") ==> "banans"
(leave-at-most 2 #\s "bananas") ==> "bananas"
Alternatives:
Fahlman suggests declaring "it is an error" for the value of :COUNT to be
negative. This has the advantage of making all current implementations'
behavior legal, no matter how bizarre. The disadvantages are that this
will be counterintuitive for beginners; it is less in keeping with the
spirit of the present wording of CLtL; and it will make functions such as
LEAVE-AT-MOST a little more complex, by requiring the user to throw a (MAX
0 ...) expression around the value of :COUNT.
Other things to consider:
In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence. Currently it "is
an error" to specify positions less than zero or greater than the length of
the sequence. I don't think the same should apply to the :COUNT keyword.
The inputs to SUBSEQ are ordinal numbers: they specify positions, like
array subscripts. The value of :COUNT is not an ordinal, it is an upper
bound on the size of the set of affected items (which is a cardinal
number).
Cost of the change: nonzero, but clearly trivial. Given the current
wording of CLtL, no code can legally depend on the behavior of sequence
functions given negative values for :COUNT. In practice it's unlikely
that many programs presently depend on one behavior or the other; if they
do then they're already non-portable.
∂22-Aug-88 0841 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Aug 88 08:41:10 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 449450; Mon 22-Aug-88 11:40:06 EDT
Date: Mon, 22 Aug 88 11:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
To: Dave.Touretzky@CS.CMU.EDU
cc: Scott.Fahlman@B.GP.CS.CMU.EDU, CL-Cleanup@SAIL.Stanford.EDU,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: Your message
References: <5787.588152756@DST.BOLTZ.CS.CMU.EDU>,
The message of 21 Aug 88 15:36 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Your proposal had a few oddities...
- The proposal named RESTRICT-TO-INTEGERS permitted NIL.
- The two proposals were orthogonal, and I wanted to vote for both.
If it were to be broken into two proposals, they should be
Fahlman's proposal (negatives are an error) and the merger of the
two you proposed.
- The proposal was not in the standard format.
For these reasons, I rewrote your proposal into a format I could vote on.
Hope you don't mind.
----------
Issue: RANGE-OF-COUNT-KEYWORD
References: :COUNT (p247), REMOVE[-xxx] (p253), DELETE[-xxx] (p254),
[N]SUBSTITUTE[-xxx] (pp255-256)
Category: CLARIFICATION
Edit history: 21-Aug-88, Version 1 by Dave Touretzky
22-Aug-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is overly vague about legal values for the :COUNT keyword
parameters to builtin functions such as the sequence functions. It
says that the keyword ``limits the number of elements [affected]''.
Implementations have varied in their interpretation of this phrase,
however.
CLtL p247 specifies that if the :COUNT parameter to functions such
as REMOVE and DELETE ``is NIL or is not supplied, all matching items
are affected.'' Because of the placement of this requirement
outside of the description of the functions affected, some
implementations have overlooked this requirement and had to be
changed later.
CLtL doesn't say explicitly that the value of :COUNT must be an
integer, nor does it say what to do for negative values.
The fact that reasonable implementations disagree on some of the
details make this an obvious candidate for cleanup.
Proposal (RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER):
Clarify that for the functions
REMOVE REMOVE-IF REMOVE-IF-NOT
DELETE DELETE-IF DELETE-IF-NOT
SUBSTITUTE SUBSTITUTE-IF SUBSTITUTE-IF-NOT
NSUBSTITUTE NSUBSTITUTE-IF NSUBSTITUTE-IF-NOT
the following restrictions on the :COUNT keyword parameter exist:
* The value of this parameter must be NIL or an integer.
* Using a negative integer value is functionally equivalent to
using a value of zero.
Test Case:
#1: (REMOVE 'A '(A B A B) :COUNT 0) => (A B A B)
#2: (REMOVE 'A '(A B A B) :COUNT -3) => (A B A B)
#3: (REMOVE 'A '(A B A B) :COUNT NIL) => (B B)
#4: (REMOVE 'A '(A B A B) :COUNT 1.0) is an error.
#5: (REMOVE 'A '(A B A B) :COUNT 'FOO) is an error.
Rationale:
Disallowing non-integer numbers is probably the original intent and
is consistent with other functions such as NTH (p265) which accept
count-like arguments that are explicitly required to integers. This
restriction would presumably permit better optimizations in low-safety
mode on stock hardware.
Allowing NIL to be equivalent to no value allows a simplified flow
of control in some situations. For example, one can write
(DEFUN MYDEL (ITEM &OPTIONAL COUNT)
(DELETE ITEM *MYLIST* :COUNT COUNT))
where otherwise it might be necessary to write something like
(DEFUN MYDEL (ITEM &OPTIONAL (COUNT NIL COUNT-P))
(IF COUNT-P
(DELETE ITEM *MYLIST* :COUNT COUNT)
(DELETE ITEM *MYLIST*)))
Allowing negative numbers frees users from having to do an explicit
check for negative numbers when the value of :COUNT is computed by
some complicated expression. For example:
(DEFUN LEAVE-AT-MOST (N ITEM SEQUENCE &KEY (FROM-END T))
(REMOVE ITEM SEQUENCE
:COUNT (PRINT (- (COUNT ITEM SEQUENCE) N))
:FROM-END FROM-END))
(LEAVE-AT-MOST 2 #\A "BANANAS") ==> "BANANS"
(LEAVE-AT-MOST 2 #\S "BANANAS") ==> "BANANAS"
Current Practice:
[Note: Pitman didn't try these examples in KCL or CMU Common Lisp. He's
working from data in Touretzky's last draft of this proposal, so someone
from those camps might want to test the assertions made here.]
#1: All correct implementations presumably return (A B A B).
This value is consisent with this proposal.
#2: Symbolics Cloe returns (A B A B).
KCL returns (A B A B) for lists.
This value is forced by this proposal.
Symbolics Genera and CMU Common Lisp return (B B).
KCL does something bizarre for vectors (``pads with n blanks or
NILs, where -n is the value of the :count keyword parameter'',
says Touretzky.)
These implementations would have to change.
#3: All correct implementations presumably return (B B).
This value is consisent with this proposal.
Some implementations have been known to signal a wrong type
argument error in the past, but have presumably been fixed.
#4: Symbolics Genera and Symbolics Cloe return (B A B).
CMU Common Lisp returns (B B).
These behaviors are consistent with this proposal.
#5: Symbolics Cloe and Symbolics Genera signal an error.
CMU Common Lisp returns (A B A B).
These behaviors are consistent with this proposal.
Cost to Implementors:
Some implementations would have to change. These functions are typically
heavily optimized by compilers. Not only source code, but also compiler
optimizers and perhaps even microcode or hardware might have to be
modified to fully accomodate this change, so it might be quite expensive.
Cost to Users:
None for Common Lisp users. This change is an upward compatible
clarification of standard practice.
Cost of Non-Adoption:
The behavior of these functions when given degenerate keyword values would
be unintuitive. In many such cases, considerable additional user code must
be written to watch for and avoid creating such situations.
Benefits:
More compact, more intuitive, and more portable code.
Aesthetics:
This change improves language aesthetics.
Discussion:
Fahlman suggests declaring "it is an error" for the value of :COUNT to be
negative. This has the advantage of making all current implementations'
behavior legal, no matter how bizarre. The disadvantages are that this
will be counterintuitive for beginners; it is less in keeping with the
spirit of the present wording of CLtL; and it will make functions such as
LEAVE-AT-MOST a little more complex, by requiring the user to throw a
(MAX 0 ...) expression around the value of :COUNT.
In the past there has been some argument about what SUBSEQ should do when
given positions greater than the length of the sequence. Currently it
"is an error" to specify positions less than zero or greater than the
length of the sequence. Touretzky doesn't think the same should apply to
the :COUNT keyword. The inputs to SUBSEQ are ordinal numbers: they specify
positions, like array subscripts. The value of :COUNT is not an ordinal,
it is an upper bound on the size of the set of affected items (which is
a cardinal number).
Pitman supports this proposal. [Hopefully Touretzky supports it, too?]
∂22-Aug-88 0948 CL-Cleanup-mailer Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 09:48:00 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Aug 88 12:45:46 EDT
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
In-reply-to: Your message of Mon, 22 Aug 88 11:39:00 -0400.
<880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 22 Aug 88 12:45:40 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I support this proposal (NIL-OR-INTEGER), as restated by KMP. I think it
is slightly better than "is an error", though perhaps not if the change
really would cause enormous work for some implementation that has this
microcoded.
Re the first sentence in the discussion section: What Fahlman suggested was
that, in the absence of any clarification by the cleanup committee, users
should assume that "is an error" to give a negative :COUNT value. But if
we're going to go to the trouble of addressing this issue, we may as well
specify what should happen, and this proposal seems as good as any.
-- Scott
∂22-Aug-88 2241 CL-Cleanup-mailer Issue "Eliminate forced consing" re-visited
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 22 Aug 88 22:40:51 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
id AA18157; Mon, 22 Aug 88 22:36:40 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA15416; Mon, 22 Aug 88 21:39:05 PDT
Date: Mon, 22 Aug 88 21:39:05 PDT
Message-Id: <8808230439.AA15416@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: Issue "Eliminate forced consing" re-visited
Wow, what a yawn. (In response to my original proposal.) After waiting a
month for comments, flames, whatever, I decided to re-send an edited version
of my original proposal in an attempt to generate some discussion. Is anyone
else trying to compete with C programs for efficiency? Here it is:
=======================
Issue: ELIMINATE FORCED CONSING
References: CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2
Category: ADDITION
Edit history: Version 1, 20-Jul-88, Ginder
Version 2, 22-Aug-88, Ginder
Moved discussion to the discussion section.
Changed multiple value proposal, clarified
certain points.
Problem description:
Some sequence, list, and string functions in CLtL encourage a
programming style that uses excessive storage allocation compared to
libraries of routines with similar functionality in other languages,
notably C. The only options available to the Common Lisp programmer who
uses these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function. The
option of providing a sequence, list, or string into which the result of
a sequence operation should be placed is not available.
Proposal:
Add a :TARGET keyword argument to those sequence, list, and string
functions where such an argument is useful, as specified below, which
allows passing a target argument sequence into which the result of the
sequence computation is to be placed. The sequence function returns the
target sequence modified as specified below:
(1) The target sequence must accomodate elements of the type(s) in the
source sequence. Thus it would be an error to give a target string
argument if the source sequence had elements that were not of type
STRING-CHAR.
(2a) A non-list target sequence should have an allocated length long
enough to accomodate the normal result of the sequence function. It is
permissable for the target sequence to have a fill pointer; in this
case, the fill pointer is set to point immediately after the last
element filled in by the sequence computation. If the target sequence
is longer than necessary, the unneeded trailing elements are unchanged.
(2b) A list target sequence argument is extended with new conses to be
as long as necessary to accomodate the resulting sequence, if not enough
conses are supplied and the :TARGET-FROM-END keyword is nil. The last
cons of the target list whose CAR was filled by the computation is
returned as a second value. The CDR of this cons is that tail of the
target list not used to accomodate the sequence computation. (I.e., The
unused conses remain as a tail of the target list that is returned.)
This permits the programmer to save the unused conses and then
null-terminate the head of the list used for the result.
(3) A :TARGET-FROM-END keyword is supported. If non-nil, the target
sequence is filled with new elements starting at the end of the target
seqeunce, effectively reversing the order of elements of the resulting
sequence in the target. In this case, an error is signalled if the
target sequence is not long enough for the result. If the target
sequence is longer than necessary, leading elements are unchanged.
(4) :TARGET-START and :TARGET-END keywords are supported. TARGET-START
and TARGET-END determine where in the target sequence the result of the
sequence computation is placed. An error is signalled if the sub-length
of the target sequence specified by these arguments is not long enough
to accomodate the resulting sequence computation. If a longer than
necessary sub-length is specified, then the elements in the unneeded
part of the specified sub-length are unchanged.
Changed sequence functions:
subseq, copy-seq, reverse, remove, remove-if, remove-if-not,
remove-duplicates, substitute, substitute-if, substitute-if-not,
merge
Changed list functions:
copy-list, butlast
copy-alist, copy-tree, adjoin, union, intersection, set-difference,
set-exclusive-or
[no TARGET-START/END or TARGET-FROM-END, just destructive
use of the :TARGET conses]
Changed string functions:
string-trim, string-left-trim, string-right-trim, string-upcase,
string-downcase, string-capitalize
Examples:
(copy-seq '(1 2 3) :target '(a b c d e f g))
=> (1 2 3 d e f g)
(copy-seq '(1 2 3) :target '(a b c d e f g) :target-from-end t :end 5)
=> (a b 3 2 1 f g)
(remove 'a '(b b a b b a b b a b b) :count 1 :target '(3))
=> (b b b b a b b a b b) ; EQ to :TARGET arg, CDR is new conses.
;;; Note, the :TARGET arg has a fill pointer.
(substitute #\a #\b "This is a string with 2 a's"
:target "0123456789012345678901234567890123456")
=> "This is b string with 2 b's"
In a related addition, included here since it addresses the same problem
as the one above, provide extended versions of concatenate, append,
revappend, and make-string-output-stream as follows:
concatenate-into target &rest sequences
Like CONCATENATE, but the result type is determined to be
the type of TARGET. The result is TARGET containing as many
of the elements of SEQUENCES as can be accomodated by the
allocated length of TARGET. TARGET's fill pointer, if
present is set according to how many elements of TARGET ar
filled by this operation.
concatenate-into-subseq target start end &rest sequences
Like concatenate-into, but copied from SEQUENCES into the
sub-sequence of TARGET specified by START and END.
append-into target &rest lists
Like APPEND, but the copied list arguments are copied into
conses taken from TARGET. The last list in LISTS
is not copied, as in APPEND, rather, the last cons used
from TARGET is given the last list in LISTS as its cdr.
The result is EQ to TARGET (unless a single list is appended),
but contains only those conses needed to hold the appended
lists' elements. The tail of unused conses from TARGET is
returned as a second value; new conses are allocated if
TARGET supplies an insufficient number of conses.
revappend-into target x y
Like REVAPPEND, but the new conses are taken from TARGET.
The result is EQ to TARGET, but contains only those conses
needed to hold X's elements. The tail of unused conses
from TARGET is returned as a second value; new conses are
allocated if TARGET supplies an insufficient number of conses.
make-string-output-stream &optional string
Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
is provided, make the string-stream write to it rather than
a newly-allocated string. An error is signalled if the output
overflows the supplied string.
Rationale:
It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Providing a set of sequence, list, and string functions that do not
require dynamic storage allocation provides a means for writing programs
that must avoid storage allocation while running as much as possible.
Excessive storage allocation (sometimes expressed as "Lisp garbage
collects too often") is one of Lisp's most widely publicized and least
understood faults.
Current practice:
Similar functionality is provided for bit-vectors, as specified in CLtL
17.4. A related capability is provided in the destructive versions of
some of the functions extended above (e.g., REMOVE vs. DELETE).
When functionality similar to this is required, users must "roll their
own".
Cost to Implementors:
The cost of implementation of these extra sequence, list, and string
function arguments is significant, in that existing code to implement
these functions must be changed to use storage passed in as an argument
by the user.
Cost to Users:
No cost, this change upwards compatible.
Cost of non-adoption:
Some programmers will continue to "roll their own" storage re-using
code. Others will not go to this effort, but will write programs that
require much garbage collection. Lisp will continue to suffer from a
handicap in promoting efficient programs when compared to C.
Benefits:
Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement. Programmers
learning Common Lisp will be challenged to understand the difference
between allocating new storage and re-using old storage as they
understand why these arguments are supported.
Esthetics:
Neutral. This proposal is syntactically consistent with the existing
keyword arguments to sequence, list, and string functions. However, it
adds to the plethora of keyword arguments already present for many of
these functions. Stylistically, it provides stronger support for the
programming style embodied by the use of the "destructive" versions of
many Common Lisp functions.
Discussion:
My experience in several commercial Lisp applications is that avoiding
storage allocation by using programming techniques such as this may be
critical to the success of a project. The current sequence, list, and
string functions encourage an "expensive", albeit easy to use,
programming style that invites the creation of programs whose
performance suffers greatly in comparison to a C program written to
solve the same problem. This applies particularly to string-hcaking
programs written using Common Lisp versus those written using the
standard string library for C.
I submit that the cost of NOT implementing this sort of functionality is
that Common Lisp, in many cases, deserves the reputation it is gaining
of being expensive to use, not in programmer productivity, but in the
resources required by the resulting programs. While it is easier to
write programs that always allocate new storage for results, it is very
expensive compared to what average programmers write in other languages.
(Asside: I realize that this dredges up the functional programming
versus side-effect programming debate. Common Lisp already supports
"destructive" versions of many functions. Lisp compiler technology has
not progressed to the point of eliminating unnecessary storage
allocation in programs written in a purely functional style.) Sometimes
the correct trade-off is to invest extra programming effort in
development of a program in exchange for lowered resource requirements
in the delivered system. This is particularly true when the deployed
Lisp application may have thousands of instances. It may well be worth
several extra man-years of effort to use facilities such as those
mentioned above rather than pay the increased cost of deployment
thousands of times! (These costs are in the form of more expensive
hardware for deployment. This might be due to higher memory
requirements or larger disk space requirements to support a large
virtual memory image and swap space.) If Common Lisp does not provide
this capability; programmers under serious performance constraints will
choose a different language, such as C.
Many programmers encounter problems writing efficient programs in Lisp.
I've encountered numerous occurances of this problem in helping people
who are trying to write Lisp programs as part of an application that is
intended to be delivered on hardware for which someone must pay real
money. The superficial problem encountered is that the program is too
slow, or requires hardware too expensive for practical deployment. The
most common result is that the programmer gives up, proclaiming that
Lisp is too slow or too resource intensive, and rewrites his program in
C. Although the above enhancements alone are not sufficient to solve
the cited problem, something along these lines is necessary as part of a
more complete solution that might include better training of Lisp
programmers, standard support for stack consing, and ephemeral GC. The
real benefit of adopting this extension to Common Lisp (and related
extensions) is an increased chance of survival for Lisp as a viable tool
for creating deliverable applications.
A related sort of optimization that compilers should be encouraged to
support is to recognize:
(concatenate 'string (subseq ...) (subseq ...) (subseq ...) ...)
as being optimizable so as to avoid the allocation of storage for
intermediate SUBSEQ results. This is a very common programming idiom
that can, of course, be expressed using the proposed extensions to avoid
intermediate consing. However, the extensions do not provide as concise
and readable a mechanism for re-espressing this idiom as may others.
Other extensions could be considered to address this:
(1) Provide a CONCATENATE function that takes a &rest
argument of sequence/start/end triples.
(2) Provide a special form like:
(designate-subseq sequence start end)
that didn't actually allocate anything but provided an imple-
mentation-specific "handle" on the subsequence for use
in such expressions as the CONCATENATE expression above.
(They'd print as the subseq, and setf's of their elements
would destructively modify the original sequence.)
However, there is no precedent in CLtL for (1). And (2) seems like a
complex, sweeping change (for implementors) of limited benefit. Also,
it is somewhat in conflict (though more general than) displaced arrays.
Neither are proposed.
I'd likely tolerate any sort of statements in the new CL manual warning
naive users of the dangers of this programming style. I agree that it
can be mis-used and lead to nasty bugs; but sometimes the benefit is
worth the risk. I simply want Common Lisp to provide the choice.
A related issue: would adoption of these arguments eliminate the need
for parallel destructive versions for some of the affected functions?
(E.g., does REMOVE with a :TARGET argument eliminate the need for
DELETE.)
An alternative to :TARGET for the keyword name is :DESTROY.
=======================
∂23-Aug-88 0740 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88 07:39:58 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Aug 88 10:38:02 EDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: Your message of Mon, 22 Aug 88 21:39:05 -0700.
<8808230439.AA15416@trwrb.TRW.COM>
Date: Tue, 23 Aug 88 10:37:55 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Let me repeat and amplify the response I made to this proposal when it
first came out.
The destructive versions of the various sequence functions are rather
dangerous to use, and are the source of confusing and hard-to-find bugs in
code written by people who don't appreciate these dangers. On the other
hand, we are trying to produce and industrial-strength language here, and
we must provide users with SOME way to do non-consing operations on
sequences. The presence of DELETE in the language shows that were are
willing to accept the added complexity and danger when the only other
choice is inefficiency. The question is not whether the language should
allow efficient, non-consing sequence operations, but how we can best
package them to reduce the danger.
At present, the principal alternative to using CONS-intensive sequence
functions is to write your own loops in an iterative style. Unfortunately,
we have poor tools for iterative programming. I was not at the recent
meeting, but I believe that the iteration committee is now functioning and
plans to propose a version of the LOOP macro as an addition to the
standard. If this comes to pass, I believe that the sequence functions
will end up being used only for the simplest kinds of loops -- a
kind of shorthand that makes the programmer's intention clear in the most
common cases -- and that the more complex options in the sequence functions
will tend to atrophy from disuse. If that is right, then it makes little
sense to add another layer of complexity to these things, just at the time
when we are providing a decent alternative in the LOOP facility.
I find that even without the LOOP facility, I tend to use the sequence
functions only in simple ways, and move over to a DO loop if the situation
becomes at all complex. The positive side of this is that I make fewer
mistakes in coding, because I'm telling the program exactly what I want it
to do rather than guessing what the sequence function would do. With
sequence functions, it is easier to see at a glance what the programmer is
trying to do, but harder to tell if he's doing it exactly right. I'm not
sure if others share this preference, however.
So I believe it comes down to two questions:
1. Do we really believe that LOOP or something very close to it will be
adopted in the near future?
2. Do we believe that if the LOOP facility were part of the standard, it
would provide a better way of writing complex, non-consing loops than would
be provided by the sequence functions augmented with :TARGET or whatever?
If the answer to both questions is yes, then it makes no sense to put in
this target stuff right now. Were it not for the problem of breaking
existing code, we might even want to eliminate some of the more complex
options from the existing sequence functions. On the other hand, if the
answer to either question is no, then :TARGET or something like it should
go in.
I'd be interested in hearing opinions on this from the people who have been
using LOOP heavily, and also any informed views on when and whether we can
expect a proposal on improved iteration machinery.
-- Scott
∂23-Aug-88 0819 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88 08:19:29 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00525; Tue, 23 Aug 88 11:19:14 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA12481; Tue, 23 Aug 88 11:20:55 EDT
Message-Id: <8808231520.AA12481@mist.UUCP>
To: "trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU"@multimax
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue "Eliminate forced consing" re-visited
In-Reply-To: Your message of Mon, 22 Aug 88 21:39:05 -0700.
<8808230439.AA15416@trwrb.TRW.COM>
Date: Tue, 23 Aug 88 11:20:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I support the general idea of this proposal. It fits in our charter,
fills a real need, and is well enough specified to be considered.
However, the form of the proposal needs some more work.
- The name should probably be changed to something like
"SEQUENCE-FUNCTION-CONSING" to come to fit our naming convention.
As Larry said about another recent proposal, I doubt that you
could find "ELIMINATE" in CLtI and even you could it probably
wouldn't point to sequence functions.
- I'd suggest "SEQUENCE-FUNCTION-CONSING:TARGET-KEYWORDS" as a
proposal name.
- The proposal text should be rewritten as if it were the new parts
of the manual/standards document. I'd certainly understand some
abbreviation to keep from having to rewrite the whole sequence
chapter and a large part of the list chapter.
- The CONCATENATE and APPEND additions should either be moved into
the proposal section or into a second issue (which I would probably
also support).
All-in-all, this has moved from what I remember as more a philosophical
statement than a cleanup proposal to something that I think we can,
and should, pass unless we are prepared to "depreciate" the sequence
functions entirely.
The main objection to this proposal seems to be Scott's belief that
LOOP can and will replace the sequence functions for most purposes. I
half agree in that: while I don't think replacing sequence functions by
LOOP is a good thing, I do think that replacing them by OSS would be
good. The critical difference is that OSS provides the functional
view of these operations that is important for some programming
styles. You could say that it comes back down to C versus Lisp again;
if I have to write everything as DO-loops, why am I using Lisp?
∂23-Aug-88 1114 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 23 Aug 88 11:13:52 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04760; 23 Aug 88 18:41 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Tue, 23 Aug 88 18:59:01 BST
Message-Id: <29596.8808231759@subnode.aiai.ed.ac.uk>
To: trwrb.uucp!smpvax1!jrg@ucbvax.berkeley.edu,
pierson <@multimax.arpa:pierson@mist>
Subject: Re: Issue "Eliminate forced consing" re-visited
Cc: cl-cleanup@sail.stanford.edu
> Date: Tue, 23 Aug 88 11:20:52 EDT
> From: "Dan L. Pierson" <pierson%mist@arpa.multimax>
> However, the form of the proposal needs some more work.
> - The proposal text should be rewritten as if it were the new parts
> of the manual/standards document. I'd certainly understand some
> abbreviation to keep from having to rewrite the whole sequence
> chapter and a large part of the list chapter.
Really? Do we supposedly even know what the format is yet?
> All-in-all, this has moved from what I remember as more a philosophical
> statement than a cleanup proposal to something that I think we can,
> and should, pass unless we are prepared to "depreciate" the sequence
> functions entirely.
I think that is going a bit far. Surely the sequence functions are
not nearly useless without this change. (Recall, for example, that
some of them just search.)
I would be interested in an informed opinion on how much of the
excess allocation can be eliminated by soemthing like OSS and how
much still requires destructive operations. I also wonder whether
OSS-like optimizations could be added to ordinary CL compilers for
some class of operations involving the normal sequence functions.
> The main objection to this proposal seems to be Scott's belief that
> LOOP can and will replace the sequence functions for most purposes.
I do not thing LOOP will really do this. Think of concatenation.
It's much easier to call CONCATENATE than to write the loop, so
one would probably end up writing a destructive procedure with
LOOP inside it rather than using LOOP directly.
BTW, one useful weapon in the war against C would be the ability to
read n characters into a buffer (string?, array?, I don't care).
It's a pain to scan a file allocating a string for every READ-LINE.
Destructive READ-LINE might do, I suppose. It also would be useful
(as was suggested in the proposal) to be able to refer to a
subsequence without actually extracting it. DESIGNATE-SUBSEQ
can probably be written in CL (sort of like locatives are written
in T), but not efficiently (and you couldn't have the normal
sequence functions work on them (except maybe via CLOS)).
-- Jeff
∂23-Aug-88 1158 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88 11:57:48 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA03620; Tue, 23 Aug 88 14:57:44 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA12684; Tue, 23 Aug 88 14:59:25 EDT
Message-Id: <8808231859.AA12684@mist.UUCP>
To: Jeff Dalton <"jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax>
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue "Eliminate forced consing" re-visited
In-Reply-To: Your message of Tue, 23 Aug 88 18:59:01 -0000.
<29596.8808231759@subnode.aiai.ed.ac.uk>
Date: Tue, 23 Aug 88 14:59:23 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
> All-in-all, this has moved from what I remember as more a philosophical
> statement than a cleanup proposal to something that I think we can,
> and should, pass unless we are prepared to "depreciate" the sequence
> functions entirely.
I think that is going a bit far. Surely the sequence functions are
not nearly useless without this change. (Recall, for example, that
some of them just search.)
Sorry, I don't mean that the sequence functions are useless without
this change. "Depreciate" is a technical term from some other
language standard (Fortran?) that means the feature is left in this
version of the language but may (will?) be removed in a future
version. My point was that if we consider the sequence functions a
desirable part of the language, this enhancement is worthwhile. If we
don't want to enhance them because we expect them to become obsolete
we should also make that clear.
I would be interested in an informed opinion on how much of the
excess allocation can be eliminated by soemthing like OSS and how
much still requires destructive operations. I also wonder whether
OSS-like optimizations could be added to ordinary CL compilers for
some class of operations involving the normal sequence functions.
The only class of OSS functions that have to cons are some of the
reducers (I don't believe that anything else does cons at run time,
but haven't gone over the source to make sure). For example:
Rlist items => list
This function creates a list of the elements in items in order.
This could easily be extended to:
Rlist items &optional list => list
This function creates a list of the elements in items in order. If
an optional list is supplied the items are placed in it ...,
otherwise a new list is created.
There are only two sequence functions not supported by OSS: REVERSE,
and SORT (and their variants). As I understand it, the problem with
supporting OSS by compiler optimization with no extensions is that
efficient compilation of compositions of OSS functions depends on
adherence to a specific set of constraints. The OSS package checks
for and either corrects or signals violations of these constraints.
For example (using some examples from part one of Dick's manual):
This works:
(OR (Rfirst (Tpositions (EQ ITEMP (Elist UNIVERSE))))
This doesn't work:
(letS* ((VALUES (Evector VALUE-VECTOR))
(WEIGHTS (Evector WEIGHT-VECTOR))
(SQUARES (* VALUES VALUES))
(WEIGHTED-SQUARES (* SQUARES WEIGHTS)))
(LIST (Rvector SQUARES) (Rvector WEIGHTED-SQUARES)))
This works:
(letS* (((VALUES WEIGHTS) (Tcotruncate (Evector VALUE-VECTOR)
(Evector WEIGHT-VECTOR)))
(SQUARES (* VALUES VALUES))
(WEIGHTED-SQUARES (* SQUARES WEIGHTS)))
(LIST (Rvector SQUARES) (Rvector WEIGHTED-SQUARES)))
It seems likely that an "ordinary CL compiler" could support some
OSS-style optimization, but it would probably be restricted to a much
smaller subset of compositions of sequence operations than OSS. It
would also be harder for a compiler to deal with cases it couldn't
optimize because, since the programmer hadn't declared any intent, the
compiler would be unable to distinguish between normal code to which
an optimization didn't apply and a programmer error that prevented an
intended optimization. For these reasons, I think that something like
OSS is needed. However anything accepted in CL should certainly fit
better into the CL naming world.
∂23-Aug-88 1230 CL-Cleanup-mailer Issue "Eliminate forced consing" re-visited
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 23 Aug 88 12:29:48 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04197; Tue, 23 Aug 88 15:29:38 EDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 23 Aug 88 15:28:12 EDT
Received: by joplin.think.com; Tue, 23 Aug 88 15:28:08 EDT
Date: Tue, 23 Aug 88 15:28:08 EDT
From: gls@Think.COM
Message-Id: <8808231928.AA03926@joplin.think.com>
To: pierson%mist@multimax.arpa
Cc: "jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK"@multimax.arpa,
cl-cleanup@sail.stanford.edu@multimax.arpa
In-Reply-To: Dan L. Pierson's message of Tue, 23 Aug 88 14:59:23 EDT <8808231859.AA12684@mist.UUCP>
Subject: Issue "Eliminate forced consing" re-visited
Date: Tue, 23 Aug 88 14:59:23 EDT
From: Dan L. Pierson <pierson%mist@multimax.arpa>
> All-in-all, this has moved from what I remember as more a philosophical
> statement than a cleanup proposal to something that I think we can,
> and should, pass unless we are prepared to "depreciate" the sequence
> functions entirely.
I think that is going a bit far. Surely the sequence functions are
not nearly useless without this change. (Recall, for example, that
some of them just search.)
Sorry, I don't mean that the sequence functions are useless without
this change. "Depreciate" is a technical term from some other
language standard (Fortran?) that means the feature is left in this
version of the language but may (will?) be removed in a future
version. ...
"Deprecate"
--Guy
∂23-Aug-88 1650 CL-Cleanup-mailer loop vs. sequence functions
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 23 Aug 88 16:50:43 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.30)
id AA07440; Tue, 23 Aug 88 16:46:32 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA07858; Tue, 23 Aug 88 16:18:22 PDT
Date: Tue, 23 Aug 88 16:18:22 PDT
Message-Id: <8808232318.AA07858@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu, fahlman@c.cs.cmu.edu
Subject: loop vs. sequence functions
At Inference, we've been using an iteration facility based on the Interlisp
iterator facility heavily for several years. We provide a public, supported
version of this to our customers as part of ART, our expert system building
tool. The iterator facility is much like the LOOP facility, to my under-
standing, though I believe that the LOOP facility may clean up a few of the
less-clean aspects of using iterators. My point is that we've had a large
user base writing Common Lisp programs in an environment where a good iteration
facility is available. They still use sequence functions. Many write
iterations, but almost all use sequence functions in addition, often in
preference to iteration. Sometimes this is based on the judgement that the
sequence functions are easier to read. Sometimes this is based on the
(almost always mistaken) belief that the Lisp compiler will turn a sequence
operation with appropriate declarations into better code than the iteration
expands into. More often the reason is the former, for sake of clarity.
I'm arguing that in our experience, a good iteration facility did not eliminate
use of the sequence functions (else I wouldn't have proposed the :target
argument).
In addition, I have another motive in this. Part of the problem is one of
education. People take courses that teach them Common Lisp syntax. These
courses rarely teach how to write reasonably efficient programs -- at least
the students don't come away able to write efficient programs. These courses
tend to focus on teaching what Common Lisp functions do and what the various
arguments are used for, then ask students to write programs using them to
show that they understand the explanation. They usually don't get into
performance considerations to any significant degree. Perhaps if we added
a :target argument for re-using conses, it would be taught and explained as
a way to avoid consing were that is appropriate. This would provide a
tangible syntactic mechanism that would be taught and explained in a manner
that made it clear to students that storage was being allocated when sequence
functions are used in the straightforward manner versus when the :target
argument was used. Granted, this depends on the structure of the course,
etc, but at least there would be some piece of syntax that could be matched
with teaching this important concept.
Another part of the proposal was sort of an addendum to address this same
issue in non-sequence, list, or string functions. This part of the proposal
has parts that are analogous to the :target argument and thus either redundant
or not based on the expected utility of LOOP. But other parts would not be
addressed by LOOP, namely the make-string-output-stream function.
Just to throw some fuel onto the fire, an alternative to the :target argument
would be to support a FREE-SEQUENCE function that returned a sequence to Lisp
for later re-use. When the Lisp could make use of this previously-allocated
storage rather than cons new storage, it would, particularly in the sequence,
list, and string functions in preference to new allocation. The advantage
to this is that it adds less syntactic baggage to the language. The dis-
advantage is that is makes it less obvious where the underlying implementa-
tion is re-using storage, leaving much to the implementation. For products
such as ART, which are marketed as minimizing the need for garbage collection,
this might pose a problem since we need to be very sure that the implementation
is re-using storage as much as possible. Of course, we could have both...
∂23-Aug-88 2308 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88 23:08:11 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 88 23:05:42 PDT
From: masinter.PA@Xerox.COM
Date: 23 Aug 88 23:04:02 PDT
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Mon, 22 Aug 88
21:39:05 PDT, <8808230439.AA15416@trwrb.TRW.COM>
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.EDU
Message-ID: <880823-230542-1393@Xerox>
I've not been as quick as I should have; the issue name should be something like
SEQUENCE-FUNCTIONS-CONSING and the proposal name something like
SEQUENCE-FUNCTIONS-CONSING:ADD-TARGET.
It might help if you were prepared to offer a portable implementation of these
functions. Do you have evidence that they are implementable efficiently?
The discussion section is much too long. We've opted for terseness, its helped,
and will be especially important if we have as many issues as I hope we will.
Can the main points be summarized, in outline form?
∂23-Aug-88 2317 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Aug 88 23:17:37 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 23 AUG 88 23:12:43 PDT
From: masinter.PA@Xerox.COM
Date: 23 Aug 88 23:11:02 PDT
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Tue, 23 Aug 88 10:37:55
EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU, cl-cleanup@sail.stanford.EDU
Message-ID: <880823-231243-1402@Xerox>
What do you think about the possibility of putting (some/all/most) of the
sequence functions and also the iteration macros in the same category of
"required library"?
The category is that: any conforming implementation of the standard must provide
them. However, they are only available to programs that REQUIRE them. So, if you
want to use LOOP, you must say (require "LOOP"). If you want to use sequence
functions, you must say (require "SEQUENCE") or some such.
The reason is that it reduces the size of the mimimal image, but allows programs
to assume that the facilities are available if they're really needed.
∂24-Aug-88 0808 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 08:07:53 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 24 Aug 88 11:06:24 EDT
To: masinter.PA@Xerox.COM
cc: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU, cl-cleanup@sail.stanford.EDU
Subject: Re: Issue "Eliminate forced consing" re-visited
In-reply-to: Your message of 23 Aug 88 23:11:02 -0700.
<880823-231243-1402@Xerox>
Date: Wed, 24 Aug 88 11:06:09 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
What do you think about the possibility of putting (some/all/most) of the
sequence functions and also the iteration macros in the same category of
"required library"?
I don't see what this suggestion buys us. If these modules are not
required to be provided by every implementation, then they can't be used in
portable code. If they are required, as you are proposing, then the
implementors have to do the work and the library modules are
sitting out there taking up disk space. Implementations are already free
to provide a GC-for-delivery facility that flushes everything not required
by a given application; they are also free to provide an autoload facility
that doesn't load this stuff until someone touches it. All your proposal
does is to replace this autoload with an explicit require, hassling the
user.
Furthermore, I think that if both iteration and sequence libraries are
standardly available, both will be used to some extent and both libraries
will almost always be loaded. The problem is that you don't want to drag
in the version with all the hairy optimizers for obscure cases just because
the user happened to call MEMBER. If you're going to play this
minimal-core game, you want to partition these packages and drag in only
the relevant chunks. I suspect that sooner or later this business of
creating minimal core images for delivery of finished applications will
become an area of competition among the vendors. We don't want to
foreclose their options by mandating a single crude partioning.
My objection to including both a LOOP facility and further extensions to
the sequence functions had nothing to do with core image size; the cost I
was worried about was the added conceptual load on the user of learning two
distinct ways of doing the same thing, both of which are rather complex and
dangerous for the careless.
By the way, I don't really buy Ginder's argument that the :target extension
is good because it will force people teaching Common Lisp to mention
consing issues. I think they will either do that or not, depending on the
interests of the teacher and the goals of the course. Having some obscure
keyword in the language that drags this in will not make a difference in
very many cases. DELETE is already present, so if Ginder were right, the
problem is already solved.
However, I do put some weight on his comments about people preferring to
use the sequence functions even when a good iteration facility is
present, largely because it makes it clear what the program is trying to
do. If others agree with this observation, I'm ready to support this
proposal in principle, though some details need to be fixed up.
-- Scott
∂24-Aug-88 2030 CL-Cleanup-mailer required libraries to reduce image size
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 20:30:37 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA06846; Wed, 24 Aug 88 20:25:43 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA04503; Wed, 24 Aug 88 20:13:39 PDT
Date: Wed, 24 Aug 88 20:13:39 PDT
Message-Id: <8808250313.AA04503@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: required libraries to reduce image size
I see nothing in Common Lisp as it stands that prevents an implementation
from having sequence functions or some other part of Common Lisp auto-loaded
upon demand. While this does not eliminate the space in the image for the
symbols identifying the autoloaded functions, this overhead should be only
a few K, at most. Would this suffice as a substitute for Masinter's suggestion
that parts of the standard be in required libraries? Since it seems permissible
already, perhaps this might eliminate some debate over what should be in such
libraries, etc.
--Joe Ginder
Larry: Sorry for no direct reply, my mailer seems to be unable to parse your
return address! Sigh.
∂24-Aug-88 2107 CL-Cleanup-mailer oops, important mis-speak in previous mail, correction included
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 21:06:53 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA06684; Wed, 24 Aug 88 20:18:07 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA04497; Wed, 24 Aug 88 20:13:36 PDT
Date: Wed, 24 Aug 88 20:13:36 PDT
Message-Id: <8808250313.AA04497@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: oops, important mis-speak in previous mail, correction included
The first sentence should have been: "Common Lisp programmers need a way
of specifying already-allocated data structures as the **TARGET** of
sequence, list, and string computations."
∂24-Aug-88 2111 CL-Cleanup-mailer brief summary of issue "Eliminate Forced Consing"
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 24 Aug 88 21:11:27 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA06670; Wed, 24 Aug 88 20:17:10 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA04491; Wed, 24 Aug 88 20:13:32 PDT
Date: Wed, 24 Aug 88 20:13:32 PDT
Message-Id: <8808250313.AA04491@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: brief summary of issue "Eliminate Forced Consing"
Common Lisp programmers need a way of specifying already-allocated data
structures as the source of sequence, list, and string computations.
Allow this via use of a :target keyword argument for those functions
where this is useful. The TARGET argument should be a sequence of the
appropriate type which is filled in with the result of the computation
This is returned rather than a newly-allocated data structure. The
proposal also mentioned a couple of analogous additions to allow similar
specification of storage to use as the result of appending and concatenating,
along with allowing specification of a string to use for string-output-
streams.
Jeff Dalton pointed out that you'd like to be able to read into a specified
buffer sometimes instead of consing, particularly with READ-LINE.
The whole idea is to allow re-use of old data structures to minimize GC's
and new allocation.
Skip the discussion and just read the preceding parts of the message to
avoid the admittedly verbose discussion but still get the changes suggested.
∂25-Aug-88 1056 CL-Cleanup-mailer Re: Issue "Eliminate forced consing" re-visited
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 25 Aug 88 10:55:36 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05999; 25 Aug 88 18:16 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Thu, 25 Aug 88 18:39:00 BST
Message-Id: <16024.8808251739@aiai.ed.ac.uk>
To: pierson <@multimax.arpa:pierson@mist>
Subject: Re: Issue "Eliminate forced consing" re-visited
Cc: cl-cleanup@sail.stanford.edu
> Date: Tue, 23 Aug 88 14:59:23 EDT
> From: "Dan L. Pierson" <pierson%mist@arpa.multimax>
>
> > and should, pass unless we are prepared to "depreciate" the sequence
> > functions entirely.
>
> I think that is going a bit far. Surely the sequence functions are
> not nearly useless without this change.
>
> Sorry, I don't mean that the sequence functions are useless without
> this change. "Depreciate" is a technical term [...] the feature [...]
> may (will?) be removed in a future version. If we don't want to enhance
> them because we expect them to become obsolete we should also make that
> clear.
I don't see how this explanation invalidates my point. This change is
not: something we should pass unless we think the sequence functions are
obsolete/perhaps-subject-to-removal anyway (and so not worth bothering to
improve). That is, we might think the sequence functions are worth having
and still not want this change.
> As I understand it, the problem with supporting OSS by compiler
> optimization with no extensions is that efficient compilation of
> compositions of OSS functions depends on adherence to a specific set
> of constraints. The OSS package checks for and either corrects or
> signals violations of these constraints.
[I don't insist on *no* extensions.]
> It seems likely that an "ordinary CL compiler" could support some
> OSS-style optimization, but it would probably be restricted to a much
> smaller subset of compositions of sequence operations than OSS.
Why is this? It can detect the cases where the constraints aren't
met. Isn't this the same as recognizing the cases where they can be
met? OK, it can't "correct" any cases that violate the constraints.
How much depends on corrections?
> It would also be harder for a compiler to deal with cases it couldn't
> optimize because, since the programmer hadn't declared any intent, the
> compiler would be unable to distinguish between normal code to which
> an optimization didn't apply and a programmer error that prevented an
> intended optimization.
All that this seems to amount to is that the compiler can't signal an
error: all it can do is not make the optimization. But that's what
compilers normally do when they can't make an optimization.
∂25-Aug-88 1721 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 25 Aug 88 17:21:01 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 450864; Thu 25-Aug-88 20:19:38 EDT
Date: Thu, 25 Aug 88 20:19 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-COUNT-KEYWORD (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Dave.Touretzky@CS.CMU.EDU, Scott.Fahlman@B.GP.CS.CMU.EDU, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880822113935.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880826001946.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve of RANGE-OF-COUNT-KEYWORD:NIL-OR-INTEGER. It's interesting
that Genera fails with a negative count for lists, but not for vectors,
I'll get that added to the test suite.
∂27-Aug-88 1111 CL-Cleanup-mailer Issue ELIMINATE FORCED CONSING (Version 2) [formerly "Eliminate forced consing" re-visited]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Aug 88 11:11:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 451384; Sat 27-Aug-88 14:10:15 EDT
Date: Sat, 27 Aug 88 14:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue ELIMINATE FORCED CONSING (Version 2) [formerly "Eliminate forced consing" re-visited]
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8808230439.AA15416@trwrb.TRW.COM>
Message-ID: <19880827181012.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 22 Aug 88 21:39:05 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
I think this is a reasonable proposal that needs a bit more work and some
simplification. One can argue about whether it's better to provide these
storage reusing operations or to provide a good garbage collector, but I
think it makes a great deal of sense, in the context of Common Lisp, to
provide both.
I think the name :OVERWRITE would be more consistent with the rest of
Common Lisp than the name :TARGET. It makes it clearer that this
argument is storage to be overwritten with new information.
When you say
(1) The target sequence must accomodate elements of the type(s) in the
source sequence.
I believe this is wrong. It should refer to the type of the elements of the
-result- of the function, not the source.
I don't understand the need for the :TARGET-FROM-END feature and I think
you should drop it from the proposal.
The last cons of the target list whose CAR was filled by the computation is
returned as a second value. The CDR of this cons is that tail of the
target list not used to accomodate the sequence computation.
I think this feature is unnecessary and should be discarded. I think
extra conses should simply be thrown away. Most people exploiting this
non-consing feature are more likely to use vectors than lists, I feel.
If the feature is kept, the second value should be the cdr of what you
propose it to be, and the result should be null-terminated in the
correct place; that should not be left to the caller to do.
Another idea would be to allow the user to pass in a function that is
called whenever storage is to be allocated. Perhaps it would take two
arguments and the default would be #'APPLY. The first argument would
be one of #'CONS, #'MAKE-LIST, or #'MAKE-ARRAY, the second argument
would be a list of arguments with dynamic extent. I'm not real fond
of this idea, but it does provide maximum generality.
(4) :TARGET-START and :TARGET-END keywords are supported.
These seem useful but should be named :OVERWRITE-START and :OVERWRITE-END.
The functions SUBSEQ, COPY-SEQ, COPY-LIST, and BUTLAST need not be
modified, because the functionality is already available from REPLACE.
The functions COPY-ALIST and COPY-TREE should not be modified, because
their use of storage is too complex to fit into this model (they don't
deal in linear sequences). The function ADJOIN should not be modified,
because a non-consing version is trivial for a user to write, and
because the consumption of storage is conditional, which would
complicate the interface.
I don't think UNION, INTERSECTION, SET-DIFFERENCE, and SET-EXCLUSIVE-OR
should be modified, because their conditional consumption of storage
would complicate the interface (unused storage has to be handed back to
the caller) and because the destructive versions that already exist can
solve the same problem, in my experience. (They aren't completely
non-consing, but they minimize consing.) You forgot to mention SUBST,
but I think the same reasoning applies and SUBST should not be modified.
This leaves REVERSE, MERGE, REMOVE, REMOVE-IF, REMOVE-IF-NOT,
REMOVE-DUPLICATES, SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM, STRING-UPCASE,
STRING-DOWNCASE, STRING-CAPITALIZE. I think it's reasonable to
modify these in the way you suggest. Doing just these makes for
a much simpler proposal that is easier to understand.
MAKE-STRING-OUTPUT-STREAM should follow the same rules as
WITH-OUTPUT-TO-STRING when a string is supplied, instead of
the different rule you suggested. With that change to make it
consistent, I support what you propose.
This leaves CONCATENATE, APPEND, REVAPPEND, and MAP (which you forgot,
but which has been discussed in the past), which take &rest arguments
and therefore are a problem. I don't think the -into-subseq version is
useful enough to justify the extra complexity. I also don't think the
extra complexity of allowing the caller to pass in too many conses to
APPEND and REVAPPEND and get back the unused ones as a second value is
justified. In fact, I think I would prefer to omit APPEND-INTO from the
proposal (CONCATENATE-INTO and NCONC should suffice) and therefore to
omit REVAPPEND-INTO also. I support CONCATENATE-INTO and MAP-INTO.
Current practice: Symbolics Common Lisp already has MAP-INTO.
(2) Provide a special form like:
(designate-subseq sequence start end)
that didn't actually allocate anything but provided an imple-
mentation-specific "handle" on the subsequence for use
in such expressions as the CONCATENATE expression above.
(They'd print as the subseq, and setf's of their elements
would destructively modify the original sequence.)
This is identical to displaced arrays, unless you propose it to work
for lists as well, in which case it is nearly unimplementable. I think
it should be dropped.
I'd support your proposal if you simplify it more or less along the lines
I suggested. I don't support version 2 because there is too much in it.
∂30-Aug-88 1158 CL-Cleanup-mailer DISALLOW-CLOSED-STREAM-FUNCTIONS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88 11:58:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16097; Tue, 30 Aug 88 11:57:21 PDT
Date: Tue, 30 Aug 88 11:57:21 PDT
Message-Id: <8808301857.AA16097@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: DISALLOW-CLOSED-STREAM-FUNCTIONS
Issue: DISALLOW-CLOSED-STREAM-FUNCTIONS
References: CLOSE (p 332)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
Problem Description:
The description of CLOSE is not completely clear about the functions
which are allowed to be performed on a closed stream.
On p332 it says:
"The stream is closed. No further Input/output operations may be
performed on it. However, certain inquiry operations may still
be performed, ..."
but the list of inquiry operations is not specified.
At least one implementation interpreted the list to include
at least OUTPUT-STREAM-P, while another has disallowed that operation
to be performed on a closed stream.
Proposal (DISALLOW-CLOSED-STREAM-FUNCTIONS:ALL)
Clarify that it is an error to perform any operation on a closed stream.
Rationale:
This clarification allows existing implementations to maintain the status
quo, while alerting users to the fact that the result of performing
an operation on a closed stream is undefined in the standard.
Also, the descriptions of OUTPUT-STREAM-P and INPUT-STREAM-P indicate
that these functions can only be performed on streams that have not
been closed.
Current Practice:
At least two implementations differ in which functions are allowed to be
performed on a closed stream.
Adoption Cost:
None.
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
None.
Aesthetics:
None.
Discussion:
∂30-Aug-88 1201 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88 12:00:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16276; Tue, 30 Aug 88 11:59:00 PDT
Date: Tue, 30 Aug 88 11:59:00 PDT
Message-Id: <8808301859.AA16276@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: RETURN-VALUES-UNSPECIFIED
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the execution
of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from
these constructs.
Current Practice:
Adoption Cost:
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
Aesthetics:
None.
Discussion:
∂30-Aug-88 1201 CL-Cleanup-mailer ARGUMENTS-UNDERSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 30 Aug 88 12:01:13 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16405; Tue, 30 Aug 88 12:00:02 PDT
Date: Tue, 30 Aug 88 12:00:02 PDT
Message-Id: <8808301900.AA16405@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: ARGUMENTS-UNDERSPECIFIED
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
PARSE-INTEGER start,end non-negative integers
PARSE-INTEGER start,end non-negative integers
SET-SYNTAX-FROM-CHAR to-char,from-char
characters
READ and others eof-value T
SET value T
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
Adoption Cost:
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
Aesthetics:
None.
Discussion:
∂31-Aug-88 1513 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 31 Aug 88 15:12:51 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213745; Wed 31-Aug-88 18:11:53 EDT
Date: Wed, 31 Aug 88 18:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880831181117.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Issue: TAIL-RECURSION-OPTIMIZATION
References: 5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
Category: CHANGE
Edit history: 31-Aug-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Useful tail-recursion optimizations are not permitted by CLtL because
the compiler must assume that any opaque function call might change
the definition of a function in between calls to that function, so a
direct jump to the code is not appropriate.
The best a compiler can do right now is approximately:
(IF (EQ #'FOO ...what compiler expects...)
...fast jump...
...standard function calling sequence...)
Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT):
Permit tail-recursion optimizations in some situations, but do not
require them.
Specifically, with SPEED=0, the compiler should not produce
tail-recursion optimizations (for the sake of tracing, stack debugging,
and reloading in interactive debugging), but with in other with higher
speed settings, it is permitted to make such optimizations.
Specify that the NOTINLINE declaration can be used within a function
to inhibit tail recursive calls from within that function, regardless
of the OPTMIZE SPEED setting.
Specify that the NOTINLINE proclamation can be used to globally
inhibit tail recursive calls to a particular function, regardless
of the OPTMIZE SPEED setting.
Test Cases:
#1: (DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
(COND ((= X 0) N)
(T (FACTORIAL-2 (- X 1) (* N X)))))
The compiler is permitted to (but not required to) treat this
as if the following had been written instead:
(DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
(LABELS ((FACTORIAL-2 (X &OPTIONAL (N 1)))
(COND ((= X 0) N)
(T (FACTORIAL-2 (- X 1) (* N X)))))
(FACTORIAL-2 X N)))
#2: (DEFMACRO DEFUN-AUTOLOADING (NAME FILE)
`(PROGN (PROCLAIM '(NOTINLINE ,NAME))
(DEFUN ,NAME (&REST ARGUMENTS)
(LET ((OLD-ME #',NAME))
(LOAD ,FILE)
(LET ((NEW-ME #',NAME))
(WHEN (EQ OLD-ME NEW-ME)
(ERROR "Function ~S was undefined after autoload." ',NAME))
(APPLY NEW-ME ARGUMENTS))))))
(DEFUN-AUTOLOADING FOO "foo.lisp")
(DEFUN BAR (X) (FOO X))
The compiler must not make assumptions about the contents of FOO,
so the function BAR will always see the current definition of FOO even
in the face of runtime redefinition.
Rationale:
Tail recursion optimization is an important source of speed improvement.
Program modularity is of key importance to many Common Lisp programmers,
and it would be rash to say that the compiler could simply violate function
boundaries at whim. Nevertheless, for Common Lisp to successfully compete
with other languages, it should be designed in a way that at least permits
implementations to make this optimization.
This proposal is designed to achieve a workable compromise between issues of
speed and debuggability.
Some implementations do tail recursion removal already even when it is
not permitted. Such implementations have an unfair benchmark advantage over
"correct but slow" implementations in the marketplace. This would even the
odds for those implementations who would do the optimization if only it were
correct.
Current Practice:
Symbolics Genera and Symbolics Cloe not currently do tail recursion
optimization. As such, they are compatible with the proposal.
Cost to Implementors:
None. This permits action for those interested in taking it, but does
not require any action.
Cost to Users:
Small. Some users who do runtime redefinition of functions would have to
add some declarations if they were compiling code with SPEED>0.
Cost of Non-Adoption:
Lisp would show up poorly against other languages in certain benchmarks.
Lisp vendors who do this optimization even though it's technically not
correct would continue have an unfair business advantage over vendors
over those who respect the rules of the language.
Benefits:
Compilers which chose to implement the optimization in question would
be able to produce better code.
Aesthetics:
No major aesthetic impact.
Discussion:
Pitman explored a number of different variants of this proposal before
sending this one. He's not wedded to the details here, but just tried to
submit something that would sound plausible. If there are ways to change
things which would make this proposal more palatable, he's happy to
hear them.
Charles Hornig (Symbolics) observes that SPEED=0 is perhaps not quite
the right criterion. The issue of whether absolute values of the
OPTIMIZE qualities are what's of interest or only relative values of
the different qualities is an open topic. For now, this proposal uses
SPEED 0 just to be conservative. If everyone can agree on something
broader, we could change the proposal. Alternatively, we can just
adopt that part of the proposal `as is' and work on a separate proposal
on how to deal with OPTIMIZE qualities.
∂31-Aug-88 1632 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 31 Aug 88 16:32:45 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213776; Wed 31-Aug-88 19:22:16 EDT
Date: Wed, 31 Aug 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
As indicated in the discussion below, I think this is really a rough
cut, but I think the issue it treats is a real one so I figured I'd
see what others think.
-kmp
-----
Issue: PROCLAIM-SCOPE
References: PROCLAIM (pp156-157)
Category: ADDITION
Edit history: 26-Aug-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
It would be useful to be able to do PROCLAIM without worrying about cleaning
up afterward. For example, a file containing:
In some cases, such as SPECIAL, there is no way to disable the effect of a
proclamation.
In other cases, such INLINE and SAFETY, it is possible but inconvenient to
change the declaration later. Even so, there is no way of inquiring about the
previous value in order to correctly restore it.
Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):
Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
the scope of a proclamation.
(PROCLAIM proclamation :LOCALLY T)
In a file, this would put the PROCLAMATION into effect for the entire
rest of time during which the file was being loaded (including
recursive loads).
Interactively, it would be the same as :LOCALLY NIL.
(PROCLAIM proclamation :LOCALLY NIL)
In a file or interactively, this would put the PROCLAMATION into
effect permanently. (The declaration would not be retracted when the
file was done loading.)
Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-NON-PERVASIVE):
Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
the scope of a proclamation.
(PROCLAIM proclamation :LOCALLY T)
In a file, this would put the PROCLAMATION into effect for the entire
rest of the current file. Recursive loads or compilations would rebind
this to the global default.
Interactively, this would affect interactive work but would not
affect the default for files loaded.
(PROCLAIM proclamation :LOCALLY NIL)
In a file or interactively, this would put the PROCLAMATION into
effect permanently, affecting the default for files in which no
local proclamation overrode it. (The declaration would not be retracted
when the file was done loading.)
Test Case:
Given a file "FOO" containing:
(PROCLAIM '(OPTIMIZE (SPEED 0) (SAFETY 3)) :LOCALLY T)
...
Doing
(LOAD "FOO")
would not clobber the global default for SPEED/SAFETY.
Rationale:
This would address several existing problems with CL...
- Declarations of optimize qualities such as speed/safety
- Absence of UNSPECIAL declaration
Macsyma has a lot of files which do (PROCLAIM '(SPECIAL ...)) at the
top of the file and then does an implementation-specific
(PROCLAIM '(UNSPECIAL ...)) at the bottom for implementations that
support it. It would be both more modular and more portable to do
something such as what is proposed here.
Current Practice:
Symbolics Cloe binds optimization qualities (SAFETY, SPEED,
COMPILATION-SPEED) in file compilations and doesn't allow
them to affect the global default.
Cost to Implementors:
[I imagine the level of difficulty in providing this feature is in the
low to intermediate difficulty range. It's not likely to be trivial for
anyone, but I doubt anyone is going to claim that it is prohibitively
expensive if we can get the details right and show that it satisfies a
real need. -kmp]
Cost to Users:
None. This is a compatible change.
Cost of Non-Adoption:
Programmers would continue to clobber each others environments with pervasive
SPEED and SAFETY proclamations.
Benefits:
It would be possible to proclaim SPEED/SAFETY information locally in a file
without worrying about the pervasive effect on other code compiled/loaded
subsequently in the same environment.
Aesthetics:
Probably people would find that this kind of flexibility had a beneficial
effect on program aesthetics.
Discussion:
Pitman has no firm opinion on this issue at this time, but believes that
something like this might be quite useful if we could iron out the details.
∂31-Aug-88 2112 CL-Cleanup-mailer 3 new cleanups
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 21:12:11 PDT
Date: Wed 31 Aug 88 15:23:03-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: 3 new cleanups
To: cl-cleanup@sail.stanford.edu
Message-ID: <12426885902.53.BECKERLE@XX.LCS.MIT.EDU>
Following this message are 3 new cleanup issues that I hope are not
too late for consideration at the October x3j13 meeting.
They've been delayed this long because I've been hoping for a real
arpanet connection, but alas, I've decided to kermit to MIT-XX and
revive my account there to do this.
...mike beckerle.
-------
∂31-Aug-88 2112 CL-Cleanup-mailer lambda-cleanup
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 21:12:21 PDT
Date: Wed 31 Aug 88 15:24:41-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: lambda-cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886201.53.BECKERLE@XX.LCS.MIT.EDU>
Issue: LAMBDA-IS-OPERATOR
References: X3J13/86-010, x3j13/86-019 pg 4.
Category: Compatible Change
Edit History: v0 28june88 mike beckerle
Problem Description:
The symbol LAMBDA in common lisp has odd status. It is not an
operator of any kind, but is recognized by other forms, like
FUNCTION, as a syntactic construct indicating that an expression
represents a function.
One must write (FUNCTION (LAMBDA ...)) or #'(LAMBDA ...)
to indicate an anonymous function in common lisp, where
simply (LAMBDA ...) would be just as clear.
The proposal FUNCTION-TYPE passed in June 88 by x3j13 takes
significant steps to help clarify the difference between functions,
and lists which "look" like functions. LAMBDA-NON-OPERATOR goes
further in this direction.
Proposal: LAMBDA-IS-SPECIAL-FORM
LAMBDA should be a special form which denotes a function.
In the light of the FUNCTION-TYPE proposal, this means that
lambda-expressions would denote objects of type FUNCTION, and that
quoted lambda expressions would denote objects of type LIST.
Proposal: LAMBDA-IS-MACRO
Define lambda as a standard macro as follows:
(defmacro lambda (&rest body)
`(function (lambda ,@body)))
Discussion:
One of the most confusing aspects of lisp for naive users is the
confusion in lisp between "meta" programming, and "higher-order"
programming. By meta programs I intend programs which manipulate the
lists which are the syntax of other programs; for example, macros are
usually "meta" programs. Higher-order programs, on the other hand,
are programs which accept functions as arguments and return functions
as results.
Since meta-programming and higher-order programming are really
orthogonal techniques, it is better to avoid confusing the two.
Particularly since both are difficult programming techniques.
The key characteristic of meta-programming in lisp is use of QUOTE,
quoted expressions, list manipulation, and either explicit or
implicit use of the lisp interpreter, EVAL, (or the compiler).
Higher-order programming does not involve the distinction between
programs and lists that look like programs, hence, whether EVAL is
called or not is irrelevant. Higher-order programming is currently
confused with meta-programming by many lisp programmers. This cleanup
taken with the FUNCTION-TYPE cleanup would make the distinction much
clearer; hence, make learning and understanding common-lisp programs
easier.
If LAMBDA-IS-SPECIAL-FORM was adopted, then one can explain the
FUNCTION special-form primarily as a way of distinguishing between
the function and value definitions of a variable. It also allows
(FUNCTION (LAMBDA ...)) to be equivalent to (LAMBDA ...) for backward
compatibility. For LAMBDA-IS-MACRO, explaining LAMBDA in terms of
(FUNCTION (LAMBDA ...)) seems conceptually less simple. Note that
accepting LAMBDA-IS-SPECIAL-FORM still allows all implementations to
define it using the macro definition if they wish.
Note that this change is orthogonal to any changes made to the
language to support '(lambda (...) ...) as an argument to funcall,
apply, etc. This was the subject of much debate when the
FUNCTION-TYPE proposal was considered at the June 88 x3j13 meeting.
Hence, if FUNCTION-TYPE is ammended to allow some common lisp
operations to accept lists and coerce them to functions,
the LAMBDA-IS-OPERATOR proposal would be unaffected.
Implementation Impact:
LAMBDA-SPECIAL-FORM would require very minor changes to any programs
which have code-walkers.
Some implementations do not allow LAMBDA to be defined as a macro.
These implementations are already not in conformance with CLtL.
-------
∂31-Aug-88 2112 CL-Cleanup-mailer list type cleanup
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 21:12:49 PDT
Date: Wed 31 Aug 88 15:25:52-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: list type cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886415.53.BECKERLE@XX.LCS.MIT.EDU>
Issue: LIST-TYPE-SPECIFIER
References: CLtL, pg 26, 27, 43.
Category: Compatible Change
Edit History: v0 28june88 mike beckerle
Problem Description:
There is a need in common lisp for more accurate type specifiers
for lists. In particular, there is no way to express
the type of a list having particular element types.
Resolving this issue will help resolve FUNCTION-TYPE-REST-LIST-ELEMENT.
Proposal: LIST-TYPE-EXTENDED
(1) The LIST type specifier would be extended to allow
specification of arguments. e.g.,
(typep x 'list) => unchanged from current meaning
(typep x '(list <subtype>)) == (and (typep x 'list)
(typep (car x) <subtype>))
(typep x '(list <s1> <s2> ... <sN>)) ==
(and (typep x 'list)
(typep (car x) <s1>)
(typep (cadr x) <s2>)
...
(typep (car (last x)) <sN>))
Hence, the LIST type specifier is extended to allow specification of the
types of the arguments.
(2) A new type specifier is added: LIST-OF.
(typep x 'LIST-OF) = error.
(typep x '(list-of <elttype>)) == (and (typep x 'list)
(dolist (elem x T)
(unless (typep x <elttype>)
(return nil))))
Discussion:
The addition of these type specifiers allows resolution of the
FUNCTION-TYPE-REST-LIST-ELEMENT proposal in a way which will allow
type-specifiers to still be highly specific about the types of
elements passed in &rest arguments.
In particular, (function (&rest (list-of number)) number), can be
distinguished from (function (&rest (list complex fixnum bignum))
number).
-------
∂31-Aug-88 2113 CL-Cleanup-mailer CLOS standard class cleanup
Received: from XX.LCS.MIT.EDU by SAIL.Stanford.EDU with TCP; 31 Aug 88 21:13:01 PDT
Date: Wed 31 Aug 88 15:28:13-EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Subject: CLOS standard class cleanup
To: cl-cleanup@sail.stanford.edu
cc: beckerle@XX.LCS.MIT.EDU
Message-ID: <12426886843.53.BECKERLE@XX.LCS.MIT.EDU>
Issue: STANDARD-CLASS-OVERHEAD
References: CLOS 88-002R pg 1-43, 1-46.
Category: CHANGE
Edit History: v0 27june88 mike beckerle
Problem Description:
The class STANDARD-CLASS allows not only for object-oriented
programming, with multiple-inheritance, but also allows for
non-trivial meta-object programming, including the operation
CHANGE-CLASS.
It is likely that many applications will make no use of
class-redefinition. All pre-CLOS common lisp applications are
examples of this. Given the new Condition/Error component of CL they
will have to run in a world which has error/condition objects in it,
yet since they are pre-clos, they will certainly make no-use of
class-redefinition.
Unfortunately, the code for accessing/updating instance-variables of
an object is significantly more complex if the class can be changed
at run time. See discussion item below on instance-variable-access-
overhead.
Proposal: Standard-class-made-simpler.
The class standard-class should be defined to not-allow
class-redefinition at run time. Compilers would be authorized
to issue compile-time errors if they could determine that
a class of meta-class standard-class was being
redefined programatically.
Proposal: Change-class-names
The name Standard-class is misleading. Eliminate the
name standard class and introduce two names for "predefined"
classes. One of which does not support class-redefinition
and the other of which does.
Suggested names are:
a) non redefinable class redefinable class
b) standard-class standard-redefinable-class
c) simple-class changeable-class
d) static-class dynamic-class
Discussion: instance-variable-access-overhead.
This issue of standard-class overhead was raised prior to the
june 88 x3j13 meeting. The CLOS committee replied to this
issue as follows:
"In addition, we don't believe that this functionality causes any
performance problems. Experience with New Flavors and PCL has shown
that there is no performance penalty incurred by including this
functionality in CLOS."
This discussion is intended to provide a more detailed notion of the
kinds of overhead involved.
Using a simple model of instance variable access, If classes cannot
be redefined at program run-time, then instance-variable access can
be coded into 3 unchecked indirections, and instances can be stored
as linear vectors of slots.
Using similar technology, but allowing class-redefinition requires 2
unchecked indirections, and 1 checked indirection, thereby requiring
a conditional branch. In addition, instances must be represented
using an extra indirection (or an optional indirection) to the actual
slots, thereby requiring 1 extra pointer in each object
representation.
Example:
(defclass foo
(x y z))
(defun bar (&optional (obj (make-instance 'foo)))
(foo-x obj))
Without class redefinition, foo-x can be inline coded as the following
common-lisp code:
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
(instance-slot obj i-v-offset)))
where instance-slot is like svref, it just indexes instance objects
directly the way svref indexes simple vectors. This assumes that
instances have a flat structure, containing no indirections to the
instance variables themselves. They are like structures, but the
access mechanism allows for multiple-inheritance.
Machine-code wise, this can be inline coded as something like:
move r1, <obj> ; r1 points at the object.
move r2, (r1 object-class-num) ; absolute offset from r1 base.
; r2 = class number
movad r3, *perm-vectors* ; absolute address load.
move r2, (r3+r2) ; indexed off r3 base.
; r2 = permutation vector
move r2, (r2 i-v-number) ; absolute offset from r3 base
; r2 = instance-var offset in object.
move r1, (r1+r2) ; indexed off r1 base.
; r1 = instance-var value.
This is a six instruction sequence involving no jumps, hence, no
pipeline breaks on processors with instruction pipelining.
To support class-redefinition using similar technology:
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
(if (slot-exists-p i-v-offset)
(let ((i-v-structure (instance-slot ,i-v-structure-offset)))
(svref i-v-structure i-v-offset))
(error "Slot ~A no longer exists in object ~S"
'x obj))))
This assumes that instances have an indirected structure, that is, in
order to get at an instance variable, one must always indirect
through a fixed location in each instance to obtain a vector of the
slots. This allows the number of instance variables to increase if
needed.
Machine-code wise, this would be coded as something like:
move r1, <obj> ; r1 points at the object.
move r2, (r1 object-class-num) ; absolute offset from r1 base.
; r2 = class number
movad r3, *perm-vectors* ; absolute address load.
move r2, (r3+r2) ; indexed off r3 base.
; r2 = permutation vector
move r2, (r2 i-v-number) ; absolute offset from r3 base
cmp r2, invalid-slot ; absolute comparison.
je :noslot ; conditional branch.
; r2 = instance-var offset in i-v-structure.
move r1, (r1 i-v-structure) ; absolute offset from r1 base
; r1 = i-v-structure.
move r1, (r1+r2) ; indexed off r1 base.
; r1 = instance-var value.
jmp :done ; unconditional jump
:noslot
.... call error ....
:done
Note that this involves 4 more instructions, not including any
to report the error, plus 1 jump (hence pipeline break on pipelined
processors.). There is no way to rearrange this code so that there
is no branch required.
I make no claims that these code sequences are optimal, but only that
they are representative of the relative complexity of instance
variable access when supporting and not-supporting class redefinition.
I belive that on conventional machine architectures, instance-variable
access could be twice as fast if the compiler could insure that
the class could not be redefined at run-time. In addition, each
instance can be smaller.
If a CLOS application used only the non-redefinable class, then
the functions involved in the class-change operations can be removed
from run-time systems.
To sumarize, there seems to be significant enough overhead required to
support class-redefinition, both in object representation, code-size,
and execution speed to justify inclusion of a meta-class which
does not allow class-redefinition in the standard.
Cost of Adoption:
Effectively zero, as CLOS was only accepted into the standard recently.
In addition, an implementation should be free to implement the
non-redefinable class in the exact same way as the redefinable class,
(possibly signaling an error on redefinition attempts).
Cost of Non-Adoption:
Due to runtime delivery considerations it is likely that vendors
will provide implementation specific class definitions which do not
have the class-redefinition capability.
-------
∂31-Aug-88 2118 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 31 Aug 88 21:17:56 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate id AA05222g; Wed, 31 Aug 88 20:17:06 PST
Received: by kent-state id AA03523g; Wed, 31 Aug 88 21:15:50 PDT
Date: Wed, 31 Aug 88 21:15:50 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8809010415.AA03523@kent-state>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 31 Aug 88 18:11 EDT <880831181117.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
This is not tail-recursion optimization. This is more properly called
EARLY-FUNCTION-BINDING. As it happens, early function binding is
often combined with tail-recursion optimization in the case of self
calls. This has led to some confusion between the two, but in fact
they are orthogonal. To clarify, tail-recursion optimization means
not consuming stack space for a function call when the result of that
call will be the result of the function making the call. Early
function binding means committing to a particular function definition
for a name before the call itself, in Common Lisp usually referring to
a commitment to a particular definition when there is the possibility
of a redefinition which would invalidate that commitment. Either or
both of these optimizations may be applied to both self calls and
calls to other functions.
∂01-Sep-88 0847 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Sep 88 08:47:38 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 1 Sep 88 11:46:14 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-reply-to: Your message of Wed, 31 Aug 88 19:21:00 -0400.
<880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Thu, 01 Sep 88 11:45:55 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU
A problem I see with your suggested use of scoped SPECIAL proclamations is
that it works with "compiled" code and not "interpreted" code. In our
interpreter, at least, a variable is only considered globally special when
there is a global special declaration currently in effect.
Given that the language currently doesn't address the issue of
compiler/interpreter differences, it seems dangerous to implicitly mandate
a clear compiler/interpreter incompatibility.
I believe that it isn't feasible to define different compiler and
interpreter semantics. This means that "portable Common Lisp" must
restrict itself to constructs that work both in compiled and interpreted
code. Either the interpreter must do preprocessing to maintain the
"compiler" semantics, or compiled code must be constrained to do things
that work in the interpreter.
Rob
∂01-Sep-88 1040 CL-Cleanup-mailer Re: CLOS standard class cleanup
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Sep 88 10:40:33 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 01 SEP 88 10:14:50 PDT
Date: Thu, 1 Sep 88 10:13 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: CLOS standard class cleanup
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <12426886843.53.BECKERLE@XX.LCS.MIT.EDU>
Message-ID: <19880901171316.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Wed, 31 Aug 88 15:28:13 EDT
From: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
Issue: STANDARD-CLASS-OVERHEAD
References: CLOS 88-002R pg 1-43, 1-46.
Category: CHANGE
Edit History: v0 27june88 mike beckerle
Without class redefinition, foo-x can be inline coded as the following
common-lisp code:
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
(instance-slot obj i-v-offset)))
To support class-redefinition using similar technology:
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo)))
(if (slot-exists-p i-v-offset)
(let ((i-v-structure (instance-slot ,i-v-structure-offset)))
(svref i-v-structure i-v-offset))
(error "Slot ~A no longer exists in object ~S"
'x obj))))
Actually, there is an important bug in this code. In both the class
redefinition and non class redefinition case there needs to be a check
to make certain the slot exists as a local slot in the instance. If
not, a trap handler must be called to check whether it could be a shared
slot or just doesn't exist. There is no way of knowing this at compile
time. So, these should be re-written as:
; without redefinition
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo))))
(if (null i-v-offset)
(trap obj 'x)
(instance-slot obj i-v-offset))))
;with redefinition
(defmacro foo-x (obj)
`(let* ((obj ,obj)
(perm-vector (svref *perm-vectors* (object-class-number obj)))
(i-v-offset (svref perm-vector ,(i-v-number 'x 'foo))))
(if (null i-v-offset)
(trap obj 'x)
(let ((i-v-structure (instance-slot ,i-v-structure-offset)))
(svref i-v-structure i-v-offset)))))
So, you can see that both cases involve a test and jump. The only
difference is one an additional memory read, and in a method which does
multiple slot accesses, this additional read can be amortized over all
those accesses.
In addition, it is worth pointing out that there is a trivial
implementation strategy which uses the faster case and allows
redefinition. Under this strategy, classes which have been redefined
pay a penalty for instance access, but other classes do not.
-------
∂01-Sep-88 1105 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 1 Sep 88 11:05:09 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213936; Thu 1-Sep-88 14:04:14 EDT
Date: Thu, 1 Sep 88 14:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
To: eb@LUCID.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809010415.AA03523@kent-state>
Message-ID: <880901140348.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 31 Aug 88 21:15:50 PDT
From: Eric Benson <eb@lucid.com>
This is not tail-recursion optimization...
You're right. I'm familiar with the distinctions you're making and am guilty
of sloppy wording.
In the meantime -- while I rewrite the proposal to refer to "early binding"
rather than "tail recursion" where appropriate -- could you please comment on
whether you are likely to support such an ammended proposal, or if not, why
not? (I'll also try to broaden the set of test cases to include a
non-tail-recursive example in which early binding just for clarity.)
Are your objections more than ones of mere terminology and classification?
Do you want to use something other than INLINE? Do you want to contest the
chosen defaults? Do you think this is a non-issue? These are the kinds of
questions I'd like to see answered. I'd like to not have discussion of this
proposal fall off just because of some (admittedly glaring) wording problems.
∂01-Sep-88 1123 CL-Cleanup-mailer lambda-cleanup
Received: from JASPER.SCRC.Symbolics.COM ([128.81.41.58]) by SAIL.Stanford.EDU with TCP; 1 Sep 88 11:23:11 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by JASPER.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 213940; Thu 1-Sep-88 14:22:13 EDT
Date: Thu, 1 Sep 88 14:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: lambda-cleanup
To: beckerle@XX.LCS.MIT.EDU
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12426886201.53.BECKERLE@XX.LCS.MIT.EDU>
References: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <880901142148.0.KMP@GRYPHON.SCRC.Symbolics.COM>
A proposal called LAMBDA-FORM is already on the table to address
the issue you raise. I'll forward you a copy. If you find there
are issues which your proposal raises which were not in mine,
maybe we can do some merging...
∂01-Sep-88 1210 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Sep 88 12:10:51 PDT
Received: from kent-state ([192.9.200.24]) by heavens-gate id AA05438g; Thu, 1 Sep 88 11:10:06 PST
Received: by kent-state id AA03819g; Thu, 1 Sep 88 12:08:50 PDT
Date: Thu, 1 Sep 88 12:08:50 PDT
From: Eric Benson <eb@lucid.com>
Message-Id: <8809011908.AA03819@kent-state>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Thu, 1 Sep 88 14:03 EDT <880901140348.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
I support this proposal completely, assuming it is reworded as you
indicate. In fact, Lucid has already implemented and documented this
proposal, exactly as you describe it. Early function binding is done
on all self calls, not just self tail calls, unless the function is
declared or proclaimed NOTINLINE. In our model, SPEED=0 means
everything is NOTINLINE. This is in knowing violation of the Law
(civil disobedience?), but we have never to my knowledge received a
bug report from a customer about it.
∂01-Sep-88 1422 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Sep 88 14:22:12 PDT
Received: by ti.com id AA29992; Thu, 1 Sep 88 16:19:23 CDT
Received: from Kelvin by tilde id AA11924; Thu, 1 Sep 88 16:04:07 CDT
Message-Id: <2798139957-9660596@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 1 Sep 88 16:05:57 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-Reply-To: Msg of Wed, 31 Aug 88 19:21 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
> Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):
>
> Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
> the scope of a proclamation.
>
> (PROCLAIM proclamation :LOCALLY T)
> In a file, this would put the PROCLAMATION into effect for the entire
> rest of time during which the file was being loaded (including
> recursive loads).
While being loaded or while being compiled? Most PROCLAIMs affect what
happens at compile-time, not load time.
> Interactively, it would be the same as :LOCALLY NIL.
This probably should be considered an error since it isn't meaningful, but
some implementations might give it a meaning, such as being local to the
current process.
> Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-NON-PERVASIVE):
>
> Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
> the scope of a proclamation.
>
> (PROCLAIM proclamation :LOCALLY T)
> In a file, this would put the PROCLAMATION into effect for the entire
> rest of the current file. Recursive loads or compilations would rebind
> this to the global default.
>
> Interactively, this would affect interactive work but would not
> affect the default for files loaded.
This approach sounds more like what the user would expect (like lexical
scoping instead of dynamic scoping), although it would be a little harder
to implement.
> Macsyma has a lot of files which do (PROCLAIM '(SPECIAL ...)) at the
> top of the file and then does an implementation-specific
> (PROCLAIM '(UNSPECIAL ...)) at the bottom for implementations that
> support it. It would be both more modular and more portable to do
> something such as what is proposed here.
This doesn't seem to be a very convincing example. There shouldn't be any
need to routinely undo SPECIAL declarations if packages are being used
correctly.
> Current Practice:
>
> Symbolics Cloe binds optimization qualities (SAFETY, SPEED,
> COMPILATION-SPEED) in file compilations and doesn't allow
> them to affect the global default.
Likewise on the TI Explorer. (PROCLAIM '(OPTIMIZE ...)) affects the
compilation but is not included in the object file. (PROCLAIM '(SPECIAL
...) doesn't affect the global environment until the object file is
loaded.
--
This issue interacts with the EVAL-WHEN problems being considered by the
compiler committee. If EVAL-WHEN can be extended and/or clarified to
permit specifying actions local to COMPILE-FILE, that might make an
extension to PROCLAIM unnecessary.
-- David Gray
∂01-Sep-88 1437 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 1 Sep 88 14:37:30 PDT
Received: by ti.com id AA00269; Thu, 1 Sep 88 16:35:15 CDT
Received: from Kelvin by tilde id AA12434; Thu, 1 Sep 88 16:27:48 CDT
Message-Id: <2798141382-9746178@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 1 Sep 88 16:29:42 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
In-Reply-To: Msg of Wed, 31 Aug 88 18:11 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
> Issue: TAIL-RECURSION-OPTIMIZATION
> References: 5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
> Category: CHANGE
> Edit history: 31-Aug-88, Version 1 by Pitman
> Status: For Internal Discussion
>
> Problem Description:
>
> Useful tail-recursion optimizations are not permitted by CLtL because
> the compiler must assume that any opaque function call might change
> the definition of a function in between calls to that function, so a
> direct jump to the code is not appropriate.
"Tail-recursion optimizations" could mean one of two things: either
a function that calls itself being optimized into a loop, or jumping to
another function while keeping the same stack frame. Your examples only
mention the first case; I don't see that the second is any problem. I'm
not even convinced that the first case is really a problem since I haven't
seen an example of meaningful code where it would not be safe to assume
that a function didn't redefine itself (other than the DEFUN-AUTOLOADING
example, which is not a likely candidate for optimization anyway). In any
case, all one would have to do to insure a run-time indirection is to do
(FUNCALL (SYMBOL-FUNCTION 'FOO) ...) instead of (FOO ...).
Anyway, I think it would be a mistake to tie this issue with the
SPEED and NOTINLINE declarations since they are intended to affect
efficiency, not the semantics of the code.
> Current Practice:
>
> Symbolics Genera and Symbolics Cloe not currently do tail recursion
> optimization. As such, they are compatible with the proposal.
The TI Explorer does do tail recursion optimization (both kinds) at higher
optimization levels. It does assume that a function won't redefine
itself, but no one has reported that as being a problem.
-- David Gray
∂01-Sep-88 2309 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Sep 88 23:09:37 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA05807g; Thu, 1 Sep 88 22:07:21 PST
Received: by bhopal id AA04511g; Thu, 1 Sep 88 23:06:39 PDT
Date: Thu, 1 Sep 88 23:06:39 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809020606.AA04511@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 31 Aug 88 19:21 EDT <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
re: Proposal (PROCLAIM-SCOPE:ADD-KEYWORD-PERVASIVE):
Introduce a :LOCALLY keyword parameter to PROCLAIM which controls
the scope of a proclamation.
(PROCLAIM proclamation :LOCALLY T)
In a file, this would put the PROCLAMATION into effect for the entire
rest of time during which the file was being loaded (including
recursive loads).
Interactively, it would be the same as :LOCALLY NIL.
(PROCLAIM proclamation :LOCALLY NIL)
In a file or interactively, this would put the PROCLAMATION into
effect permanently. (The declaration would not be retracted when the
file was done loading.)
Although you've called this a "scoping" issue, you've really made it an
"extent" issue. (See CLtL Chapter 3). The phraseology "... would put the
PROCLAMATION into effect for the entire rest of time during which the file
was being loaded ..." bears this out.
Lucid Common Lisp has a function called FILE-PROCLAIM, which has essentially
the same semantics as your proposal: It "retracts" all proclamations
made during the loading/compilation of the file. But we decided not to
recommend its use, precisely because we thought most users would confuse
the issue of dynamic extent with local scoping.
In fact, one of the issues in my "private" list of things that we at Lucid
are concerned about, but which have not had a satisfactory submissions to
the cleanup committee yet, is just the matter of a "Lexical Proclaim". In
the hardcopy sheet I handed out to many committee members, at the Palo Alto
meeting in March of this year, there should have been the paragraph:
(5) Add a lexical "pervasive" declaration special form; e.g,
(locally (pervasive-declare (special foo))
...)
has syntax like 'declare, but acts more like proclaim; it pertains only
to the lexical scope indicated -- its action is not dynamically scoped.
In particular, it differs from 'declare' in that interior binding forms
"inherit" the declaration, rather than forming a "wall" against it.
This is the functionality that I would support, even though wrapping
a 'pervasive-declare' around a 'defun' has implementational consequences
similar to wrapping a non-null 'let' [i.e., there may be a non-null
lexical environment].
-- JonL --
∂02-Sep-88 1357 CL-Cleanup-mailer reaching closure on open cleanup items
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 13:57:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 13:49:47 PDT
Date: 2 Sep 88 13:49 PDT
From: Masinter.pa@Xerox.COM
Subject: reaching closure on open cleanup items
To: cl-cleanup@sail.stanford.edu
Message-ID: <880902-134947-7091@Xerox>
I've put off cleanup for a while, but hope to get back to it seriously now. I
think that if we're going to distribute stuff in time for the October meeting
that we need to get resolution in the next three weeks. That's a pretty
heavy-duty schedule. This is to warn you to be prepared for a barrage.
∂02-Sep-88 1636 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 16:36:47 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 16:15:59 PDT
Date: 2 Sep 88 16:15 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1) formerly
DISALLOW-CLOSED-STREAM-FUNCTIONS
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 30 Aug 88
11:57:21 PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-161559-7391@Xerox>
I'm going to nitpick the name of the issue, and call the it
CLOSED-STREAM-OPERATIONS.
Frankly, I'd be unhappy if there were no way to ask a stream whether it was
closed. I would much prefer OUTPUT-STREAM-P and INPUT-STREAM-P be required to
just answer NIL on closed streams.
∂02-Sep-88 1637 CL-Cleanup-mailer Re: RETURN-VALUES-UNSPECIFIED
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 16:36:55 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 16:21:46 PDT
Date: 2 Sep 88 16:20 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: RETURN-VALUES-UNSPECIFIED
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of Tue, 30 Aug 88
11:59:00 PDT
To: chapman%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-162146-7401@Xerox>
I might quibble with a few of these:
INSPECT: it is marginally more useful to say that INSPECT returns the item
inspected. Some interactive inspectors might allow you to return a new value as
the value of INSPECT, e.g., (SETQ X (INSPECT X)).
PROVIDE and REQUIRE are not likely to appear except in the "top level" of files.
∂02-Sep-88 1844 CL-Cleanup-mailer Ooops! Issue: LAMBDA-CAR-OF-FORM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:44:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:34:13 PDT
Date: 2 Sep 88 17:34 PDT
From: Masinter.pa@Xerox.COM
Subject: Ooops! Issue: LAMBDA-CAR-OF-FORM
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
Aug 88 15:24:41 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-173413-7637@Xerox>
Sorry, I also didn't notice the message from Kent about LAMBDA-FORM. I should
have the issues sorted out over the weekend to start summarizing status early
next week.
∂02-Sep-88 1844 CL-Cleanup-mailer Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:44:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:24:33 PDT
Date: 2 Sep 88 17:24 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: LAMBDA-CAR-OF-FORM (was LAMBDA-IS-OPERATOR)
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
Aug 88 15:24:41 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-172433-7582@Xerox>
I'll take the perogative of renaming the issue.
I've always had a hard time with the "problem" in this one -- the problem is
that you have to say #'(LAMBDA ...) instead of (LAMBDA ...). However, the
proposal increases the number of special forms, since it doesn't eliminate the
need for FUNCTION. Does it make the language better to have more special forms?
Frankly, your argument about Higher-order vs Meta-programming doesn't do much
for me; its an interesting way of looking at the problem, but is it really
relevant to this issue?
∂02-Sep-88 1845 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:45:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:45:34 PDT
Date: 2 Sep 88 17:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 1 Sep 88 23:06:39
PDT
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174534-7686@Xerox>
A major concern is that any additions that talk about "file" should have some
reasonable semantic model; currently, the semantics of Common Lisp are described
in terms of expressions, without regard to file boundaries. I've thought that it
might be possible to talk about special "file" forms, that have translations
into things that can be typed in interactively.
Some possible models for "file" are
Assume each file is wrapped with an implicit "progn".
Assume each expression in a file is actually preceded with an implicit "(locally
" ...
Otherwise, we're left with an operational semantics that describes what things
*mean* only in terms of what LOAD or COMPILE *does*....
∂02-Sep-88 1845 CL-Cleanup-mailer Re: required libraries to reduce image size
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:44:53 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:42:24 PDT
Date: 2 Sep 88 17:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: required libraries to reduce image size
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 24 Aug 88
20:13:39 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174224-7678@Xerox>
Making something part of the "required library" is a way of deprecating it. It
makes it possible to relegate it to a separate package; the "require" explicitly
will make sure that the package is available before first mention.
People complain that Common Lisp is too big and complex; you have to know too
much to read a Common Lisp program. When a program is annotated with an explicit
"require", it makes it clear what other things you have to understand to
understand the module in hand.
While it might also reduce the image size, I don't see that as the primary
benefit -- rather, it helps make the language simpler by making it explicit that
some of the more seldom used features are really part of a "library" rather than
the "language".
∂02-Sep-88 1845 CL-Cleanup-mailer Re: required libraries to reduce image size
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:45:01 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:42:49 PDT
Date: 2 Sep 88 17:42 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: required libraries to reduce image size
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 24 Aug 88
20:13:39 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174249-7684@Xerox>
Making something part of the "required library" is a way of deprecating it. It
makes it possible to relegate it to a separate package; the "require" explicitly
will make sure that the package is available before first mention.
People complain that Common Lisp is too big and complex; you have to know too
much to read a Common Lisp program. When a program is annotated with an explicit
"require", it makes it clear what other things you have to understand to
understand the module in hand.
While it might also reduce the image size, I don't see that as the primary
benefit -- rather, it helps make the language simpler by making it explicit that
some of the more seldom used features are really part of a "library" rather than
the "language".
∂02-Sep-88 1845 CL-Cleanup-mailer Re: Issue: PROCLAIM-SCOPE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Sep 88 18:45:19 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 02 SEP 88 17:45:42 PDT
Date: 2 Sep 88 17:45 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: PROCLAIM-SCOPE (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Thu, 1 Sep 88 23:06:39
PDT
To: Jon L White <jonl@lucid.com>
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880902-174542-7687@Xerox>
A major concern is that any additions that talk about "file" should have some
reasonable semantic model; currently, the semantics of Common Lisp are described
in terms of expressions, without regard to file boundaries. I've thought that it
might be possible to talk about special "file" forms, that have translations
into things that can be typed in interactively.
Some possible models for "file" are
Assume each file is wrapped with an implicit "progn".
Assume each expression in a file is actually preceded with an implicit "(locally
" ...
Otherwise, we're left with an operational semantics that describes what things
*mean* only in terms of what LOAD or COMPILE *does*....
∂04-Sep-88 1447 CL-Cleanup-mailer [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 14:47:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 14:45:03 PDT
Date: 4 Sep 88 14:44 PDT
From: Masinter.pa@Xerox.COM
Subject: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue: ALIST-NIL
(Version 1)]
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: NO
Message-ID: <880904-144503-8857@Xerox>
!
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
4-Sep-88, Version 2 by Masinter (reflect discussion)
Problem Description:
NIL is permitted to be an element of an a-list but nothing useful
can be done with such an element. This is confusing to users.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
No motivation in CLtL is given for NIL being allowed in an a-list.
The description of a-lists seem needlessly complicated by this feature.
FIND (with a :KEY of #'CAR) and ASSOC (with no key) are almost identical
except for their treatment of this issue. If no one makes significant
use of the feature, it would be better to be able to simplify the
relationship between these functions.
Current Practice:
All valid implementations allow NIL.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which the author is able to guess this
feature might be used:
#1: A user might want a leading NIL on an a-list so that if the list
were empty, there'd still be a tail to which cells could be attached
in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that this is more
clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) ENTRY) ;Something unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT,
RASSOC-IF and RASSOC-IF-NOT depending on the predicate used.
Cost of Non-Adoption:
There only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
Simplified documentation. May allow ASSOC to be faster if it is no longer necessary to check explicitly for NIL.
Aesthetics:
This change would simplify the language.
Discussion:
Pitman submitted this proposal after looking at the write-up of
a-lists in the new standard. The description seems needlessly
cluttered by this unmotivated and he felt that either a motivation
for this feature should be cited and defended or the feature should
go away. The degree to which he believes in this feature will be
determined by any claims made by others in ensuing discussion.
Putting a NIL in an alist as a way of removing the element might be simpler
than putting some otherwise useless CONS, and allows for a quick (remove NIL
alist).
Some people might consider this change gratuitous.
∂04-Sep-88 1521 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 15:21:24 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 15:20:18 PDT
Date: 4 Sep 88 15:19 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Message-ID: <880904-152018-8868@Xerox>
I tried to add a current practice, etc. section.
I added some wording about other constraints to the other arguments.
Saying T as the type of eof-value and SET confused me; one might interpret,
especially since eof-value is optional, and none of the other types are named by
their type specifier.
I'm not too worried about the distinction of STRING-CHAR vs CHAR since the
character committee will propose to get rid of the distinction, but it might
otherwise come up in SET-SYNTAX-FROM-CHAR and MAKE-DISPATCH-MACRO-CHARACTER.
!
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
PARSE-INTEGER start,end non-negative integers
PARSE-INTEGER start,end non-negative integers
SET-SYNTAX-FROM-CHAR to-char,from-char
characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may signal an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. PARSE-INTEGER may signal
an error if the START or END arguments are not in the range of the "string"
argument.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
We
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
∂04-Sep-88 1559 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 15:59:20 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 15:56:22 PDT
Date: 4 Sep 88 15:56 PDT
From: Masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
Message-ID: <880904-155622-8877@Xerox>
This reminds me a little of the PATHNAME issue. I think that CLOSE is only valid
for streams that PATHNAME was valid for
What does it mean to CLOSE a composite stream ( broadcast two-way synonym
concatenated) ? The choices I can think of are:
a) no effect
b) implementation dependent (ugh)
c) closes constituent streams
d) the composite stream is "closed" (no I/O operations allowed) but
the constituents are not.
What does it mean to close a constructed stream (e.g., STRING)?
a) no effect
b) implementation dependent (ugh)
c) the constructed stream is "closed" (no I/O operations allowed).
I think the following operations should be as valid after a CLOSE as before
(i.e., they're valid after the close only if they were valid before):
STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME. (In fact, there
are some operating systems where you can *only* get TRUENAME on a closed stream,
since the name isn't true until the stream has been closed.)
Note that the issues STREAM-CAPABILITIES, STREAM-INFO, and STREAM-CLASS-ACCESS
add functions that take streams.
∂04-Sep-88 1617 CL-Cleanup-mailer Issue: COERCE (Version 1) vs COERCE-FROM-TYPE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 4 Sep 88 16:09:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 04 SEP 88 16:05:13 PDT
Date: 4 Sep 88 16:05 PDT
From: Masinter.pa@Xerox.COM
Subject: Issue: COERCE (Version 1) vs COERCE-FROM-TYPE
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 12:19 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880904-160513-8886@Xerox>
Kent: I think that the issues COERCE-FROM-TYPE and COERCE-INCOMPLETE are the
same issue, with two separate proposals. I'd like to merge the discussion of
them, since I favor the combination of the two proposals better than either one
alone, that is, add the TYPE argument, use the class precedence list to define
the priority when there is an ambiguity of how to view the type.
M.Ida brought up a good point in his message of 18 Jul 88; do we need a cleanup
to redefine TYPE-OF to be the same as (CLASS-NAME (CLASS-OF x)) ?
∂05-Sep-88 1324 CL-Cleanup-mailer Re: Potential issues?
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Sep 88 13:23:57 PDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 05 SEP 88 13:20:37 PDT
From: masinter.PA@Xerox.COM
Date: 5 Sep 88 13:18:39 PDT
Subject: Re: Potential issues?
In-reply-to: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK's message of Mon, 5 Sep
88 17:51:08 BST, <7296.8809051651@aiai.ed.ac.uk>
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Masinter.PA@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <880905-132037-9404@Xerox>
Well, my inclination is to concentrate on ambiguities over additions to the
language, except where there is some agreement in current practice.
In the area of read case sensitivity, I remember that we thought about this
issue a lot in Xerox Common Lisp, since we had to support Interlisp too, and
Interlisp was case sensitive. While Franz handles case sensitivity with a global
parameter (or is it a global state), we made it a property of the read table;
that is, the readtable could be a case sensitive or case insensitive readtable.
This preserved the property that *READTABLE* captured the variations in the
behavior of READ. It has not been a formal cleanup issue; if you want to write
one up, READ-CASE-SENSITIVITY is a good name for it.
As for READ-INTERNAL-CASE, its less clear to me what the problem is -- you
mention embarrassment, but that seems to depend too much on the perspective of
the viewer. Are you embarrassed by parentheses? By names like FMAKUNBOUND or
CADADR?
I think we withdrew PROCLAIM-LEXICAL because we couldn't figure out how to
procede. If you like, I can send you the back-mail on the issue if you want to
see if you can make some progress.
HASH-TABLE-ENTRY-EXTENT: I was expecting that the discussion on Common Lisp
would wind up as a cleanup proposal. Sounds like a good idea. Will you?
Re Symbol-macro-flet: I'm just not convinced of the utility. At least the
compilers I am familiar with go to some lengths to optimize uses of FLET and
LABELS; having another binding mechanism doesn't seem like a step forward. And
SYMBOL-MACRO-LET is under attack.
Re what the meaning of (MACROLET ((F () 'A)) #'F) might be: I believe this is an
error; I think we might even find enough evidence to convince ourselves that
CLtL says so, and that the editor merely needs make it more carefully worded.
∂05-Sep-88 1417 CL-Cleanup-mailer Potential issues?
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 5 Sep 88 14:16:06 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04323; 5 Sep 88 17:22 BST
Date: Mon, 5 Sep 88 17:51:08 BST
Message-Id: <7296.8809051651@aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Potential issues?
To: Masinter.pa@xerox.com
Cc: cl-cleanup@sail.stanford.edu
I am wondering whether it is worth raising / reviving the following
issues:
1. Read-case-sensitivity: It is difficult to make READ case-sensitive.
(Well, you might try defining lots of character macros, so perhaps it
is possible: hence the "difficult".) Case-sensitivity is useful for
certain applications. I should think something like a *READ-PRESERVE-
CASE* variable would be an appropriate solution. Has this issue been
raised before?
2. Read-internal-case: Upper case is somewhat of an embarrassment these
days and is harder to read besides. So it's a shame that Common Lisp
uses it internally. *PRINT-CASE* can be used to hide the internal case
on output, but it still appears from time to time. ExCL has (or had) a
way of dealing with this, so there is some precedent. Nonetheless, I
suspect that any attempt to change the internal case would be doomed,
except for one thing: some trick along the lines of the canonical case
suggestion for pathnames could be used to aid conversion or to hide the
internal case for read as well as print. One consequence is that, in
some setting, all upper case would mean all lower case (and vice versa),
but that may be an acceptable price to pay.
3. Proclaim-lexical: I seem to recall that this is an existing issue.
KMP's PRLCLAIM-SCOPE is related (since it would limit the scope of
special proclamations).
4. Hash-table-extry-extent: This refers to: <something like hash tables
except that entries could be removed if there was no reference to the
key except in such tables>. This issue been discussed on the CL list
but has not (as far as I know) been raised as an actual suggestion for
change. Note that such tables can be added with little work: since CL
does not require that there be a GC, it could just as well not require
that any entries actually disappear. The main question is whether they
should be presented as hash tables or as something else.
5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
looks like a variable but is really some expression. It might seem
that MACROLET does the same for function names, but it doesn't.
MACROLET applies to entire calls, not just the name. This suggests
that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.
For example:
(symbol-macro-flet ((f '(g)))
(list (f (a-list))
(apply #'f (another-list)))
would be equivalent to:
(list (funcall (g) (a-list))
(apply (g) (some-list)))
BTW, what is the meaning of (MACROLET ((F () 'A)) #'F)? In KCL and
Lucid, it seems to be the same as #'F without the MACROLET; but (F)
in the MACROLET is not the same as (F) without: this seems to be an
inconsistent interpretation of F.
-- Jeff
∂06-Sep-88 1010 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 10:09:19 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 6 Sep 88 12:36:09 EDT
Received: by joplin.think.com; Tue, 6 Sep 88 12:31:23 EDT
Date: Tue, 6 Sep 88 12:31:23 EDT
From: gls@Think.COM
Message-Id: <8809061631.AA22700@joplin.think.com>
To: Masinter.pa@xerox.com
Cc: chapman%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@xerox.com's message of 2 Sep 88 16:20 PDT <880902-162146-7401@Xerox>
Subject: RETURN-VALUES-UNSPECIFIED
Date: 2 Sep 88 16:20 PDT
From: Masinter.pa@xerox.com
I might quibble with a few of these:
INSPECT: it is marginally more useful to say that INSPECT returns the item
inspected. Some interactive inspectors might allow you to return a new value as
the value of INSPECT, e.g., (SETQ X (INSPECT X)).
I disagree. If one regards INSPECT as a tool in the interactive
interface, it can be a real nuisance to inspect some huge data structure
and then when you finish it insists on printing 300 lines of gobbledygook
at you.
--Guy
∂06-Sep-88 1753 CL-Cleanup-mailer Re: RETURN-VALUES-UNSPECIFIED
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Sep 88 17:53:09 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 SEP 88 17:42:07 PDT
Date: 6 Sep 88 17:41 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: RETURN-VALUES-UNSPECIFIED
In-reply-to: gls@Think.COM's message of Tue, 6 Sep 88 12:31:23 EDT
To: gls@Think.COM
cc: Masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com,
cl-cleanup@sail.stanford.edu
Message-ID: <880906-174207-11565@Xerox>
OK
∂07-Sep-88 0001 CL-Cleanup-mailer Revised ELIMINATE-CONSING-PROPOSAL, version 3
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 00:01:00 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA13656; Tue, 6 Sep 88 23:52:14 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA12438; Tue, 6 Sep 88 15:37:57 PDT
Date: Tue, 6 Sep 88 15:37:57 PDT
Message-Id: <8809062237.AA12438@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: Revised ELIMINATE-CONSING-PROPOSAL, version 3
Issue: ELIMINATE FORCED CONSING
References: CLtL section 14.1,3,5; 15.2,5; 17.4; 18.3; 21.2
Category: ADDITION
Edit history: Version 1, 20-Jul-88, Ginder
Version 2, 22-Aug-88, Ginder
Moved discussion to the discussion section.
Changed multiple value proposal, clarified
certain points.
Version 3, 31-Aug-88, Ginder
Revised according to various comments. Much of
my original discussion has been eliminated.
Problem description:
Some sequence, list, and string functions in CLtL encourage a
programming style that uses excessive storage allocation compared to
libraries of routines with similar functionality in other languages,
notably C. The only options available to the Common Lisp programmer who
uses these functions are to generate a newly-allocated sequence or to
destructively modify the argument sequence(s) given the function. The
option of providing a sequence, list, or string into which the result of
a sequence operation should be placed is not available.
Proposal:
Add mutually exclusive :RECYCLE or :MODIFY keyword arguments to those
sequence, list, and string functions where such arguments are useful.
:RECYCLE is used to pass a sequence to be recycled to hold the result of
the sequence, list, or string operation. :MODIFY is used to pass a
sequence that is to be modified in some manner to contain the result of
the operation. The distinction lies in that :MODIFY is akin to
destructively modifying a useful data structure, while :RECYLE is used
to simply recycle a data structure that would otherwise be useless and
possibly garbage (i.e., a data structure whose contents are no longer of
interest and may be altered arbitrarily). The sequence, list, or string
function returns the MODIFY'd or RECYLE'd sequence as specified below.
It is an error to pass both a :MODIFY and a :RECYCLE argument.
[a] Support a MODIFY argument:
(1) The sequence to be modified must accomodate elements of the type(s)
that would have been stored in a newly-allocated sequence. Thus it
would be an error to give a target string argument if the result of the
operation would normally have had elements that were not all of type
STRING-CHAR.
(2a) A non-list MODIFY argument should have an allocated length long
enough to accomodate the normal result of the sequence function. The
sequence to be modified may have a fill pointer. The fill pointer
remains unchanged by this operation so long as it points after the
modified elements of the sequence. If the fill pointer points prior to
or in the range of the modified elements, it is set to point immediately
after the last element filled in by the sequence computation. If the
sequence to be modifed is longer than necessary, the unneeded trailing
elements are unchanged.
(2b) A list MODIFY argument is extended with new conses to be as long as
necessary to accomodate the resulting sequence, if not enough conses are
supplied and the :MODIFY-FROM-END keyword is nil. Two values are
returned: the first is the modified list with any unused tail remaining
intact. (I.e., The unused conses remain as a tail of the modified list
that is returned.) The second is that tail of the original list that
was not modified by the operation. This second value is useful for
continued modification of the tail.
(3) :MODIFY-START and :MODIFY-END keywords are supported. MODIFY-START
and MODIFY-END determine where in sequence the result of the sequence
computation is placed. It is an error if the sub-length of the sequence
specified by these arguments is not long enough to accomodate the
sequence computation. If a longer than necessary subsequence is
specified, then the elements in the unneeded part of the specified
subsequence are unchanged.
(4) A :MODIFY-FROM-END keyword is supported. If non-nil, the sequence
to be modified is filled with new elements starting at MODIFY-END (e.g.,
the end of the sequence if MODIFY-END is not specified), effectively
reversing the order of elements of the as the sequence is modified. It
is an error if the supplied sequence is not long enough for the result.
If the supplied sequence is longer than necessary, leading elements are
unchanged.
Sequence functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
subseq, copy-seq, reverse, remove, remove-if,
remove-if-not, remove-duplicates, substitute, substitute-if,
substitute-if-not, merge
List functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
copy-list, butlast
String functions changed to include MODIFY, MODIFY-START, MODIFY-END,
MODIFY-FROM-END:
string-trim, string-left-trim, string-right-trim, string-upcase,
string-downcase, string-capitalize
[a] Support a RECYLE argument:
(1) The sequence to be recycled must accomodate elements of the type(s)
that would have been stored in a newly-allocated sequence. Thus it
would be an error to give a RECYLE string argument if the result of the
operation would normally have had elements that were not all of type
STRING-CHAR.
(2a) A non-list RECYCLE argument should have an allocated length long
enough to accomodate the normal result of the sequence function. The
sequence to be recycled may have a fill pointer. The fill pointer is
set to point immediately after the last element filled in by the
sequence computation. If the sequence to be recycled is longer than
necessary, the unneeded trailing elements are unchanged.
(2b) A list RECYCLE argument is extended with new conses to be as long
as necessary to accomodate the resulting list, if not enough conses are
supplied. Two values are returned: the first is the result list
terminated with NIL. (I.e., The unused conses are spliced out of the
recycled list that is returned.) The second is that tail of the
original list that was not used by the recycling operation.
(3) No :RECYCLE-START, :RECYCLE-END, or :RECYCLE-FROM-END arguments are
supported.
Changed sequence functions:
subseq, copy-seq, reverse, remove, remove-if,
remove-if-not, remove-duplicates, substitute, substitute-if,
substitute-if-not, merge
Changed list functions:
make-list, copy-list, copy-alist, copy-tree, butlast, subst,
sublis, adjoin, union, intersection, set-difference,
set-exclusive-or
Changed string functions:
string-trim, string-left-trim, string-right-trim, string-upcase,
string-downcase, string-capitalize
Examples:
(copy-seq '(1 2 3) :modify '(a b c d e f g))
=> (1 2 3 d e f g)
(copy-seq '(1 2 3) :modify '(a b c d e f g) :modify-from-end t :modify-end 5)
=> (a b 3 2 1 f g)
(remove 'a '(b b a b b a b b a b b) :count 1 :recycle '(3))
=> (b b b b a b b a b b) ; EQ to :recycle arg, CDR is new conses.
(substitute #\a #\b "This is a string with 2 a's"
:modify (make-array 37 :element-type 'string-char :fill-pointer 0))
=> "This is b string with 2 b's" ; result EQ to MODIFY arg,
; result has a fill-pointer set to 27
(substitute #\a #\b "ababa"
:modify (make-array 10 :element-type 'string-char
:initial-element #'q
:fill-pointer 10))
=> "aaaaaqqqqq" ; result EQ to MODIFY arg,
; result has a fill-pointer set to 10
(copy-list '(a b c) :recycle '(1 2 3 4 5 6 7))
=> (a b c) ; first value
(4 5 6 7) ; second value
(copy-list '(a b c) :modify '(1 2 3 4 5 6 7))
=> (a b c 4 5 6 7) ; first value
(4 5 6 7) ; second value
In related additions, included here since they address the same problem
as above, provide extended versions of concatenate, append, revappend,
make-string-output-stream, and read-line as follows:
concatenate-into target &rest sequences
Like CONCATENATE, but the result type is determined to be
the type of TARGET. The result is TARGET containing as many
of the elements of SEQUENCES as can be accomodated by the
allocated length of TARGET. TARGET's fill pointer, if
present is set according to how many elements of TARGET are
filled by this operation.
map-into target function sequence &rest sequences
Like MAP, but the result type is determined to be the type
of TARGET. The result of MAP-INTO is TARGET such that
element j is the result of applying FUNCTION to element j
of each of the argument sequences. TARGET must be as long
as the shortest of the input sequences. TARGET's fill
pointer, if present is set according to how many elements of
TARGET are filled by this operation.
append-into target &rest lists
Like APPEND, but the copied list arguments are copied into
conses taken from TARGET. The last list in LISTS
is not copied, as in APPEND, rather, the last cons used
from TARGET is given the last list in LISTS as its cdr.
The result is EQ to TARGET (unless a single list is appended),
but contains only those conses needed to hold the appended
lists' elements. The tail of unused conses from TARGET is
returned as a second value; new conses are allocated if
TARGET supplies an insufficient number of conses.
revappend-into target x y
Like REVAPPEND, but the new conses are taken from TARGET.
The result is EQ to TARGET, but contains only those conses
needed to hold X's elements. The tail of unused conses
from TARGET is returned as a second value; new conses are
allocated if TARGET supplies an insufficient number of conses.
make-string-output-stream &optional string
Like the current MAKE-STRING-OUTPUT-STREAM, except if STRING
is provided, it must be a string with a fill pointer. Output
to the resulting stream is incrementally appended to STRING,
as if using VECTOR-PUSH-EXTEND if the string is adjustable,
and otherwise using VECTOR-PUSH.
read-line-into-string string &optional input-stream eof-error-p
eof-value recursive-p
Like READ-LINE, but reads into STRING. STRING must be a string
with a fill pointer. The result of READ-LINE-INTO-STRING is
incrementally appended to STRING, as if using VECTOR-PUSH-EXTEND
if the string is adjustable,and otherwise using VECTOR-PUSH.
In order to facilitate recycling alists and trees, the following two
functions are proposed.
flatten-tree tree
FLATTEN-TREE would take a tree and return a linear list made
of all the conses in the tree, suitable for recycling via a
:RECYLE argument.
flatten-alist alist
FLATTEN-ALIST would take an alist and return a linear list
made of all the conses that would be copied by COPY-ALIST,
suitable for recycling via a :RECYLE argument.
Rationale:
It is sometimes better to use a more complex programming construct for
sake of efficiency than to use a less complex, more expensive one.
Providing a functions that do not require dynamic storage allocation
provides a means for writing programs that must avoid storage allocation
while running as much as possible. Excessive storage allocation
(sometimes expressed as "Lisp garbage collects too often") is one of
Lisp's most widely publicized faults.
Current practice:
Similar functionality is provided for bit-vectors, as specified in CLtL
17.4. A related capability is provided in the destructive versions of
some of the functions extended above (e.g., REMOVE vs. DELETE).
When functionality similar to this is required, users must "roll their
own".
[from Moon] Symbolics Common Lisp already has MAP-INTO.
Cost to Implementors:
The cost of implementation of these extra sequence, list, and string
function arguments is significant, in that existing code to implement
these functions must be changed to use storage passed in as an argument
by the user.
Cost to Users:
No cost for existing programs, this change is upwards compatible. Users
may mis-use the new keyword arguments and end up with buggy code,
similar to the problems encountered when using C library functions that
re-use data structures.
Cost of non-adoption:
Programmers will continue to "roll their own" non-standard storage
re-using code. Others will not go to this effort, but will write
programs that require much garbage collection. Lisp will continue to
suffer from a handicap in promoting efficient programs when compared to
C.
Benefits:
Those programmers choosing to invest the extra effort needed to
correctly use such facilities can do so with less overhead than
previously required, and will see performance improvement.
Esthetics:
Neutral. This proposal is syntactically consistent with the existing
keyword arguments to sequence, list, and string functions. However, it
adds to the plethora of keyword arguments already present for many of
these functions. Stylistically, it provides stronger support for the
programming style embodied by the use of the "destructive" versions of
many Common Lisp functions.
Discussion:
My experience in several commercial Lisp applications is that avoiding
storage allocation by using programming techniques such as this may be
critical to the success of a project. The current sequence, list, and
string functions encourage an "expensive", albeit easy to use,
programming style that invites the creation of programs whose
performance suffers greatly in comparison to a C program written to
solve the same problem. This applies particularly to string-hcaking
programs written using Common Lisp versus those written using the
standard string library for C.
A related issue: would adoption of these arguments eliminate the need
for parallel destructive versions for some of the affected functions?
(E.g., does REMOVE with a :MODIFY argument eliminate the need for
DELETE.)
Pierson supports the general ideas of an earlier version of this
proposal, but believes the proposal itself should be in the form that
would appear in a revised manual.
Several people responded in the negative to Fahlmans suggestion that
perhaps the new LOOP facility would relieve the need for these
extensions. Fahlman is ready to support the proposal in principle if
certain details are fixed up.
Moon does not like returning unused conses as a second value as proposed
in previous versions of this proposal. He also does not believe that
UNION, INTERSECTION, SET-DIFFERENCE, and SET-EXCLUSIVE-OR derive much
benfit from previously suggested extensions similar to those in this
proposal. Neither should the functions SUBSEQ, COPY-SEQ, COPY-LIST, and
BUTLAST be modified, because the functionality is already available from
REPLACE, he claims. He thought :TARGET should be changed to :OVERWRITE.
All of the above comments were made prior to version three of this
proposal.
MAPCAR and friends might be considered candidates for modification in
this proposal. However, these mapping functions likely will be made
obsolete by LOOP if they are not already obsolete.
∂07-Sep-88 0219 CL-Cleanup-mailer discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
Received: from ucbvax.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 02:18:51 PDT
Received: by ucbvax.Berkeley.EDU (5.59/1.31)
id AA13742; Tue, 6 Sep 88 23:56:28 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
Received: by trwrb.TRW.COM (5.51/1.36)
id AA12484; Tue, 6 Sep 88 15:38:22 PDT
Date: Tue, 6 Sep 88 15:38:22 PDT
Message-Id: <8809062238.AA12484@trwrb.TRW.COM>
To: cl-cleanup@sail.stanford.edu
Subject: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
! I think the name :OVERWRITE would be more consistent with the
! rest of Common Lisp than the name :TARGET. It makes it clearer
! that this argument is storage to be overwritten with new
! information.
The problem is that the :TARGET argument is used for two different
purposes. One is to fill a subsequence of a useful sequence, as in
filling in a substring of a longer string. The other is to recycle
storage (i.e., an obsolete sequence that would otherwise be garbage)
without regard for the previous contents of that storage (except to
insure type compatibility). It seems useful to regard these as
different operations; although, except for the list case, they often can
be conveniently denoted using the same basic syntax, as in my proposal.
Some of the modifications you suggest to the proposal seem to stem from
assuming one or the other of these uses, disregarding the other. Thus I
believe I should modify the proposal to have two different keywords that
can reflect the intention of a programmer.
For sake of argument, let's call the two keyword arguments :MODIFY (for
changing a subsequence of a useful sequence) and :RECYCLE (for recycling
a sequence that is otherwise garbage). A list passed as a :RECYCLE
argument is re-used as a linear list made of conses to recycle. CAR's
are ignored (i.e., it is not a tree of conses to re-use!).
! When you say
! (1) The target sequence must accomodate elements of the
! type(s) in the source sequence.
! I believe this is wrong. It should refer to the type of the
! elements of the -result- of the function, not the source.
I believe this is correct. My proposal will be altered to reflect this.
! I don't understand the need for the :TARGET-FROM-END feature and
! I think you should drop it from the proposal.
:TARGET-FROM-END specifies that the target sequence is filled from the
end with the result of the operation. This allows the elements of the
result sequence to be placed into the target argument in reverse order.
This is not essential to the proposal. It was included for sake of
symetry, in some sense of the word, since one might expect this
capability after surveying the other keywords available. It would
become :MODIFY-FROM-END given the distinction in usage of the target
sequence already discussed. I'll take it out if most people think it
excessive.
! The last cons of the target list whose CAR was filled by the
! computation is returned as a second value. The CDR of this cons
! is that tail of the target list not used to accomodate the
! sequence computation.
!
! I think this feature is unnecessary and should be discarded. I
! think extra conses should simply be thrown away. Most people
! exploiting this non-consing feature are more likely to use vectors
! than lists, I feel.
I do not agree that this feature will usually be limited to vectors
rather than lists. It is, however, tied to the :MODIFY/:RECYCLE
distinction. A new proposal will address the return values in light of
this distinction.
! If the feature is kept, the second value should be the cdr of
! what you propose it to be, and the result should be null-terminated
! in the correct place; that should not be left to the caller to do.
This would prevent the use of the :TARGET argument for filling in a
sublist, since the sublist is terminated. It also breaks symetry with
other sequence types where a subsequence of a larger-than-needed TARGET
sequence is filled. The problem is overloading :TARGET with the
semantics of :MODIFY and :RECYCLE. For :MODIFY semantics, you want to
return a second value which is the tail of the list that was not used,
leaving that tail linked to the head that was used. For :RECYCLE
semantics, you want as the first value the the null-terminated head of
the list that was used, and as the second value the tail that was not
used. The difference is whether the first list value is null terminated
or not. In addition, for a sequence with a fill-pointer used as the
RECYLE argument, the fill-pointer would be adjusted to point after the
last sequence element inserted. As a MODIFY argument, the fill-pointer
would remain unchanged. [Would the fill-pointer be extended if filling
the MODIFY argument used elements after the fill-pointer? Or would
those elements of the MODIFY sequence after the fill pointer remain
unchanged? I prefer the former.]
I oppose any change to the proposal that causes excess conses to be
thrown away.
! Another idea would be to allow the user to pass in a function that is
! called whenever storage is to be allocated. Perhaps it would take two
! arguments and the default would be #'APPLY. The first argument would
! be one of #'CONS, #'MAKE-LIST, or #'MAKE-ARRAY, the second argument
! would be a list of arguments with dynamic extent. I'm not real fond
! of this idea, but it does provide maximum generality.
This provides maximum generality, but requires function call overhead
that might be avoided if storage is passed directly. One might achieve
the same effect by supporting storage-freeing operations so Lisp could
keep a "free list" of recyclable storage to re-use rather than
allocating new storage. Of course this leads to the desire to preserve
storage locality, including free-lists, thus a discussion of storage
allocation areas with free-lists per area, etc. I would not oppose such
a mechanism, however.
! (4) :TARGET-START and :TARGET-END keywords are supported.
!
! These seem useful but should be named :OVERWRITE-START and
! :OVERWRITE-END.
Well, I'd say :MODIFY-START and :MODIFY-END now. :RECYCLE-START and
:RECYCLE-END are redundant with the normal :START and :END argument as
:RECYCLE implies the sequence passed in is just for storage recycling.
The :RECYCLE argument should not be used to modify a subsequence of a
useful sequence; use :MODIFY instead.
! The functions SUBSEQ, COPY-SEQ, COPY-LIST, and BUTLAST need not be
! modified, because the functionality is already available from
! REPLACE.
I believe the :RECYCLE argument should be supported for these.
! The functions COPY-ALIST and COPY-TREE should not be modified,
! because their use of storage is too complex to fit into this model
! (they don't deal in linear sequences).
Since it is well-defined when COPY-ALIST copies a cons, and since it is
well-defined that circularities and shared substructure are NOT
preserved in COPY-TREE, I see no reason not to include a :RECYLE
argument for these functions. While modifiying an existing alist or
tree using the :MODIFY argument is ill-defined, the use of the :RECYLE
argument as a glob of available, linear cons storage is quite useful.
It would be useful, given the semantics above, to provide functions to
"flatten" an alist or a tree. A new proposal will address this.
! The function ADJOIN should not be modified, because a non-consing
! version is trivial for a user to write, and because the
! consumption of storage is conditional, which would complicate
! the interface.
Again, for sake of symetry, I (mildly) disagree. The unused conses
should be returned, which is the interface complication you mention, I
guess. Of course, the TARGET argument should be changed to :RECYLE for
ADJOIN.
! I don't think UNION, INTERSECTION, SET-DIFFERENCE, and
! SET-EXCLUSIVE-OR should be modified, because their
! conditional consumption of storage would complicate
! the interface (unused storage has to be handed back to
! the caller) and because the destructive versions that
! already exist can solve the same problem, in my
! experience. (They aren't completely non-consing, but
! they minimize consing.) You forgot to mention SUBST,
! but I think the same reasoning applies and SUBST
! should not be modified.
You're correct, I forgot SUBST. However, I believe :RECYCLE should be
supported for SUBST, UNION, INTERSECTION, SET-DIFFERENCE, and
SET-EXCLUSIVE-OR.
! This leaves REVERSE, MERGE, REMOVE, REMOVE-IF, REMOVE-IF-NOT,
! REMOVE-DUPLICATES, SUBSTITUTE, SUBSTITUTE-IF, SUBSTITUTE-IF-NOT,
! STRING-TRIM, STRING-LEFT-TRIM, STRING-RIGHT-TRIM, STRING-UPCASE,
! STRING-DOWNCASE, STRING-CAPITALIZE. I think it's reasonable to
! modify these in the way you suggest. Doing just these makes for
! a much simpler proposal that is easier to understand.
To reflect the clearer set of keywords, these would be changed to
support RECYCLE/MODIFY in my new proposal.
! MAKE-STRING-OUTPUT-STREAM should follow the same rules as
! WITH-OUTPUT-TO-STRING when a string is supplied, instead of
! the different rule you suggested. With that change to make it
! consistent, I support what you propose.
I agree. This was an oversight.
! This leaves CONCATENATE, APPEND, REVAPPEND, and MAP (which
! you forgot, but which has been discussed in the past),
! which take &rest arguments and therefore are a problem. I
! don't think the -into-subseq version is useful enough to
! justify the extra complexity. I also don't think the
! extra complexity of allowing the caller to pass in too
! many conses to APPEND and REVAPPEND and get back the
! unused ones as a second value is justified. In fact, I
! think I would prefer to omit APPEND-INTO from the proposal
! (CONCATENATE-INTO and NCONC should suffice) and therefore
! to omit REVAPPEND-INTO also. I support CONCATENATE-INTO
! and MAP-INTO.
OK, I'll remove the -INTO-SUBSEQ stuff. But I disagree that passing in
too many conses and getting the unused ones back as a second value is
too complex. I think this is a big win that is extremely useful.
! I'd support your proposal if you simplify it more or less along
! the lines I suggested. I don't support version 2 because there
! is too much in it.
I'll submit a modified proposal for discussion.
-- Joe Ginder
∂07-Sep-88 1155 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Sep 88 11:55:13 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 7 Sep 88 14:52:18 EDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Subject: ELIMINATE-FORCED-CONSING
In-reply-to: Your message of Tue, 06 Sep 88 15:38:22 -0700.
<8809062238.AA12484@trwrb.TRW.COM>
Date: Wed, 07 Sep 88 14:52:00 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Through some fluke of network routing, Ginder's revised proposal reached me
before his detailed response to Moon. When I saw the :MODIFY and :RECYCLE
arguments and the complexities involved in making the latter do what you
want, my head started spinning. I think that this is all very confusing,
and I am strongly opposed to this proposal in its current form. :MODIFY
and :RECYCLE are similar enough to be easily confused, but they differ in
subtle ways in their details; I never want to have to explain to a class
when you use which one.
Once I saw Ginder's other message, I realized what the problem is: I'm
happy enough to accept a :MODIFY or :OVERWRITE option in all of the
appropriate places -- I have no preference for one of these names over the
other -- but I really don't think that any of this recycling nonsense
should be muddled in with the sequence functions. To have both :MODIFY and
:RECYCLE present, similar but different in subtle ways, is to invite
endless confusion. If we accept just the :MODIFY part of the proposal, I
think that Moon's prescriptions -- discarding excess conses, for example,
are right.
If there really is a need for recycling of CONS cells, I would support an
explicit RECYCLE call whose argument is a list. This would authorize (but
not require) and implementation to CDR down the list argument, setting the
CAR of each cell to NIL, and then to splice the whole thing onto a free
list of some sort; CONS would use these free cells before allocating new
ones. Systems with epehemeral GC might not want to implement this since it
doesn't buy much and might result in worse storage locality than just
dropping the list. Something similar could be done for arrays, structures,
etc., though that is harder to do.
In the past we always stayed away from such things, since these constructs
lead to very confusing bugs if the program is actually holding onto the
recycled structure somewhere else. However, many programs end up creating
their own resource managers to reduce garbage-creation, and perhaps it is
time to consider adding this to the language proper. In any case, I think
that mixing this recycling concept with the sequence functions is the wrong
move.
I would be prepared to support a version of this proposal that just
included the :MODIFY parts.
-- Scott
∂07-Sep-88 1225 CL-Cleanup-mailer discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 12:25:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455682; Wed 7-Sep-88 15:22:54 EDT
Date: Wed, 7 Sep 88 15:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: discussion of Moon's comments re: ELIMINATE-FORCED-CONSING
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809062238.AA12484@trwrb.TRW.COM>
Message-ID: <19880907192224.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 6 Sep 88 15:38:22 PDT
From: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
! I'd support your proposal if you simplify it more or less along
! the lines I suggested. I don't support version 2 because there
! is too much in it.
I'll submit a modified proposal for discussion.
Unfortunately the new proposal is so complicated that I'm not going to
have time to read and understand it in the near future. I was hoping
for something a lot simpler. If I get a chance to read it carefully
enough to comment on it, I'll send in some comments.
∂07-Sep-88 1226 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 7 Sep 88 12:26:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03511; Wed, 7 Sep 88 12:25:14 PDT
Date: Wed, 7 Sep 88 12:25:14 PDT
Message-Id: <8809071925.AA03511@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Edit history: #1, 7 September 1988, Walter van Roggen
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.
Unlike all the other type declarations, which can be used for discrimination
and have an implicit effect on representation, specialized FUNCTION type
specifiers thus appear to have superfluous information. By changing the
meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.
This issue does not address the use of lambda-list-keywords and
argument count matching, nor the reproclamation or additional declaration
of FUNCTION types, nor having TYPEP treat specialized FUNCTION types
as if they were just the same as the atomic FUNCTION type for purposes
of discrimination.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
For specialized FUNCTION type specifiers
(proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
(the val-type (f (the arg0-type ...) (the arg1-type ...) ...))
If the arguments to F are of the specified types, then the result will be of
the specified type. If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Adoption Cost:
None, since making use of FUNCTION declarations is "optional".
Benefits:
Better type checking and more compiler optimizations should be possible.
Conversion Cost:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
∂07-Sep-88 1423 CL-Cleanup-mailer Issue: GET-MACRO-CHARACTER-READTABLE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Sep 88 14:23:37 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 07 SEP 88 14:01:32 PDT
Date: 7 Sep 88 14:01 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: GET-MACRO-CHARACTER-READTABLE
To: cl-cleanup@sail.stanford.edu
Message-ID: <880907-140132-13143@Xerox>
----- Begin Forwarded Messages -----
Return-Path: <@RELAY.CS.NET:yuasa%tutics.tut.junet@UTOKYO-RELAY.CSNET>
Received: from CLI.COM ([10.8.0.62]) by Xerox.COM ; 07 SEP 88 11:54:15 PDT
Received: by CLI.COM (4.0/1); Wed, 7 Sep 88 13:41:37 CDT
Received: from relay2.cs.net by RELAY.CS.NET id ah10518; 7 Sep 88 13:12 EDT
Received: from utokyo-relay by RELAY.CS.NET id bu14361; 7 Sep 88 12:47 EDT
Received: by ccut.cc.u-tokyo.junet (5.51/6.3Junet-1.0/CSNET-JUNET)
id AA21863; Wed, 7 Sep 88 14:28:15 JST
Received: by nttlab.ntt.jp (3.2/6.2NTT.h) with TCP; Wed, 7 Sep 88 12:29:01 JST
Received: by tutics.tut.junet (ver3.3/6.2J/systemV)
id AA23442; Wed, 7 Sep 88 12:19:46 jst
Message-Id: <8809071219.AA23442@tutics.tut.junet>
Date: Wed, 7 Sep 88 12:19:46 jst
From: Taiichi Yuasa <yuasa%tutics.tut.junet@utokyo-relay.CSNET>
To: kcl@CLI.COM
Subject: get-macro-character
KCL does not accept NIL as the readtable argument for GET-MACRO-CHARACTER
and GET-DISPATCH-MACRO-CHARACTER. This means the only way in KCL to get
information on macro/dispatch-macro characters is to make a copy of the
standard readtable and send it to these functions.
Although CLtL does not explicitly specify these functions should accept NIL
for standard readtable, some examples in CLtL do not work in KCL.
To fix the "bug", replace the statement
check_type_readtable(&rdtbl);
in the definition of the C functions get_macro_character and get_dispatch_
macro_character in file c/read.d with
if (rdtbl == Cnil)
rdtbl = standard_readtable;
else
check_type_readtable(&rdtbl);
This bug fix was suggested by Cesar Quiroz on this mailing list.
Thanks Cesar.
-- Taiichi
----- End Forwarded Messages -----
∂07-Sep-88 1634 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 16:34:00 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455890; Wed 7-Sep-88 19:33:12 EDT
Date: Wed, 7 Sep 88 19:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880907233254.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Here's the issue writeup that I promised months ago, but never had time
to do. I hope it's not too late to be of any use to anyone.
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Problem description:
CLtL does not specify precisely when the dynamic extent (aka lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, TAGBODY, or equivalent such as PROG.
(2) Nonlocal exit from the target of a THROW or RETURN.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In cases 2 and 3, the extent could
end anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the shortest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the shortest extent consistent with CLtL maximizes freedom
for implementations and takes away no useful capability from users.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target exit at the moment the values are returned, and end the
extent of a passed-over exit at the moment the THROW, RETURN, or GO
commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
I have not surveyed any other implementations.
Cost to Implementors:
There is no cost to implementors, as no currently valid implementation
will be made invalid by this proposal.
Cost to Users:
There is no cost to users, as no existing portable program is made invalid
by this proposal. This proposal will clarify why some existing nonportable
programs are nonportable, which could be viewed as either a cost or a benefit
to users.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition will
be consistent with current practice in a way that has no cost for implementors
nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it ducks this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. This proposal
could be expanded to cover that issue by discussing the extent of
dynamic-extent entities other than exits, or that issue could be the
subject of a separate proposal.
∂07-Sep-88 1825 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 18:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455935; Wed 7-Sep-88 21:23:24 EDT
Date: Wed, 7 Sep 88 21:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809071925.AA03511@decwrl.dec.com>
Message-ID: <19880908012301.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE sounds good to me.
I have a small wording problem with it: I can't figure out what if
anything your proposal says about use of the FUNCTION type specifier
for discrimination. The problem description and conversion cost
sections sound as if you're proposing something, but the proposal
section doesn't mention it.
∂07-Sep-88 1840 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 18:40:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455941; Wed 7-Sep-88 21:38:32 EDT
Date: Wed, 7 Sep 88 21:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
cc: Masinter.pa@xerox.com, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <7296.8809051651@aiai.ed.ac.uk>
Message-ID: <19880908013813.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 5 Sep 88 17:51:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
looks like a variable but is really some expression. It might seem
that MACROLET does the same for function names, but it doesn't.
MACROLET applies to entire calls, not just the name. This suggests
that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.
This is Zetalisp's "lambda macros", also available in Symbolics Common
Lisp. They're called that because they let users write new things that
behave like LAMBDA. They're pretty useful in a few specialized
circumstances. You would of course want both a global (DEFMACRO)
version and a local (MACROLET) version. In SCL, the former is named
DEFLAMBDA-MACRO but the latter doesn't exist.
I don't strongly support adding this feature to Common Lisp, since it's
pretty specialized, but I certainly wouldn't oppose it. It would
make the language more useful and complete.
BTW, what is the meaning of (MACROLET ((F () 'A)) #'F)?
The same as the meaning of (DEFMACRO F ...) #'F except for the
scoping of F. The way this is explained in CLtL is extremely
confusing, but I think it should be an error. Point 4 of the
pending cleanup issue FUNCTION-TYPE makes it clearly an error.
In KCL and Lucid, it seems to be the same as #'F without the MACROLET
That's surely not desirable.
∂07-Sep-88 1843 CL-Cleanup-mailer Issue: CLOSED-STREAM-OPERATIONS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 18:43:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455943; Wed 7-Sep-88 21:41:50 EDT
Date: Wed, 7 Sep 88 21:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880904-155622-8877@Xerox>
Message-ID: <19880908014133.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 4 Sep 88 15:56 PDT
From: Masinter.pa@Xerox.COM
This reminds me a little of the PATHNAME issue. I think that CLOSE is only valid
for streams that PATHNAME was valid for
Certainly not. Suppose I have a stream that represents a network connection
to another computer. This stream doesn't go to a file, so it has no pathname,
but it certainly has a well-defined concept of closing.
What does it mean to CLOSE a composite stream ( broadcast two-way synonym
concatenated) ? The choices I can think of are:
a) no effect
b) implementation dependent (ugh)
c) closes constituent streams
d) the composite stream is "closed" (no I/O operations allowed) but
the constituents are not.
I prefer c.
What does it mean to close a constructed stream (e.g., STRING)?
a) no effect
b) implementation dependent (ugh)
c) the constructed stream is "closed" (no I/O operations allowed).
I prefer a or c.
I think the following operations should be as valid after a CLOSE as before
(i.e., they're valid after the close only if they were valid before):
STREAMP, INPUT-STREAM-P, OUTPUT-STREAM-P, TRUENAME, PATHNAME. (In fact, there
are some operating systems where you can *only* get TRUENAME on a closed stream,
since the name isn't true until the stream has been closed.)
Certainly.
Note that the issues STREAM-CAPABILITIES, STREAM-INFO, and STREAM-CLASS-ACCESS
add functions that take streams.
∂07-Sep-88 1853 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 18:53:13 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455948; Wed 7-Sep-88 21:52:15 EDT
Date: Wed, 7 Sep 88 21:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880622180746.5.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908015159.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor LAMBDA-FORM:NEW-MACRO. Note the message I am replying
to was mailed June 22.
∂07-Sep-88 1911 CL-Cleanup-mailer ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:10:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455952; Wed 7-Sep-88 22:06:19 EDT
Date: Wed, 7 Sep 88 22:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: ISSUE: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
To: Skona Brittain <skona%csilvax@hub.ucsb.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU, SKONA@csilvax.ucsb
In-Reply-To: The message of 26 Jul 88 19:50 EDT from Skona Brittain <skona%csilvax@hub.ucsb.edu>
Message-ID: <19880908020559.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR.
∂07-Sep-88 1913 CL-Cleanup-mailer [Masinter.pa: Re: questions]
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:13:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455955; Wed 7-Sep-88 22:11:19 EDT
Date: Wed, 7 Sep 88 22:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: [Masinter.pa: Re: questions]
To: Masinter.pa@Xerox.COM, chapman%aitg.DEC@decwrl.dec.com
cc: CL-CLEANUP@SAIL.STANFORD.EDU
In-Reply-To: <880721-082056-3692@Xerox>
Message-ID: <19880908021100.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Jul 88 08:20 PDT
From: Masinter.pa@Xerox.COM
In-reply-to: chapman%aitg.DEC@decwrl.dec.com's message of 19 Jul 88 13:55
On page 354, "When the @xlisp printer types out the name of a
special character, it uses the same table as the @f[#\] reader;
therefore any character name you see typed out is acceptable as
input (in that implementation). Standard names are always
preferred over non-standard names for printing."
I'd like to change the last sentence to read "... are required
over non-...". Do you see a problem with that?
Well, I thought preferred was put there for a reason, and I can imagine
situations where a short-name might be preferred (the case I have in mind is
NewLine. If you're running on a system that talks both to cr and lf based file
systems, you might want to emphasize #\cr #\lf vs #\newline.)
Symbolics Genera is an example of exactly such a system. Our user interface
standards require us to print #\Return rather than #\Newline for this character.
In general Common Lisp is weak on portability of the output of the PRINT function.
Adding a new feature to produce output from one implementation that is guaranteed
to be readable by all other implementations might be a good idea, but I think
it raises a lot more issues than just the names-of-characters issue.
∂07-Sep-88 1918 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:18:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455961; Wed 7-Sep-88 22:17:37 EDT
Date: Wed, 7 Sep 88 22:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880721134308.5.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
I think that's more consistent with the rest of Common Lisp.
∂07-Sep-88 1923 CL-Cleanup-mailer Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:23:23 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455964; Wed 7-Sep-88 22:22:20 EDT
Date: Wed, 7 Sep 88 22:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880627153746.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908022204.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN. It's interesting to note
that the rationale quoted from the Colander editor is weak and confused,
but the rationale in Kent's proposal (which is actually in the problem
description section) makes a lot more sense. The problem isn't file
systems that don't have types at all, but file systems that have types
for some pathnames but not for other pathnames, for example Unix.
I suggest that the proposal be extended to allow :UNSPECIFIC in the
version, directory, device, and host fields as well. The only field
that should not allow :UNSPECIFIC is the name field.
∂07-Sep-88 1935 CL-Cleanup-mailer Issue: PATHNAME-CANONICAL-TYPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:35:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455967; Wed 7-Sep-88 22:34:32 EDT
Date: Wed, 7 Sep 88 22:34 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-CANONICAL-TYPE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880707143558.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880908023415.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would favor PATHNAME-CANONICAL-TYPE:NEW-CONCEPT if some small
modifications were made, as follows:
(PATHNAME-CANONICAL-TYPE (MAKE-PATHNAME :TYPE :LISP)) => :LISP
[This information may be explicitly represented as an additional slot, or
computed on demand using a lookup table, as the implementor prefers.]
I'm not sure what your bracketed comment means, but the
important example is
(PATHNAME-CANONICAL-TYPE (PATHNAME "foo.lisp")) => :LISP
where of course the string is implementation-dependent. That is,
PATHNAME-CANONICAL-TYPE must produce a canonical type even when the
pathname was not constructed from a canonical type, but instead came
from user typein, the TRUENAME function, the DIRECTORY function,
or some similar source, when the pathname's type is one that a
canonical type maps into.
It would be good to have a facility for users (in addition to
implementations) to extend the set of canonical type names, since users
may well have their own types of files. In Genera this is named
FS:DEFINE-CANONICAL-TYPE. The difficulty is that in any system that
supports multiple file systems, FS:DEFINE-CANONICAL-TYPE has to be
complex enough to allow specification of separate mappings for each file
system, which requires a way to name file system types, but maybe that
would be too complex for some people's taste.
Define the following standard types:
:LISP ``Lisp'' (source) file
:BIN ``Compiled Lisp'' (object) file
Permit implementations to extend the set of canonical type names.
All the comments I saw were opposed to :BIN, and I oppose it too. In
fact I am opposed to any standardized name for this canonical type,
primarily because this ought to vary based on various
implementation-dependent parameters. For example, in Genera it varies
depending on the processor type. I believe that Common Lisp should
standardize only the name of a variable whose value is the canonical
type for the output of COMPILE-FILE. In Genera this variable is named
SI:*DEFAULT-BINARY-FILE-TYPE*, a really lousy name. How about
calling it *COMPILE-FILE-OUTPUT-TYPE*?
∂07-Sep-88 1942 CL-Cleanup-mailer Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:42:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455970; Wed 7-Sep-88 22:40:16 EDT
Date: Wed, 7 Sep 88 22:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PATHNAME-SYNTAX-ERROR-TIME (Version 1)
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>, Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807221702.AA02408@cdr.utah.edu>
Message-ID: <19880908023959.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 22 Jul 88 11:02:08 MDT
From: sandra%cdr@cs.utah.edu (Sandra J Loosemore)
Of the options presented for this issue, I prefer
PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION. The NAMESTRING-COERCION
option seems like it is really the wrong time, and I would rather not
leave it EXPLICITLY-VAGUE.
I favor PATHNAME-SYNTAX-ERROR-TIME:PATHNAME-CREATION also.
However, I would really like to see something completely different --
namely adding a keyword argument to TRUENAME to allow it to be used
for explicit syntax checking of filenames without signalling an error
if the file doesn't exist. Functions such as OPEN and the ones in
sections 23.3, 23.4, and 23.5 that actually pass pathnames to the host
file system would be required to (implictly or explicitly) perform the
same checking.
This would also solve a problem I brought up some time ago, that I was
having with Lucid Lisp under VMS. I had defined a logical name like
LISP$LIBRARY that expanded into something that included a directory
specifier in its expansion, like disk$login:[loosemore.lisp.library].
However, I was getting things like
(namestring (merge-pathnames
(pathname "[loosemore]foo.bar")
(pathname "lisp$library:")))
=> "lisp$library:[loosemore]foo.bar"
which the file system naturally barfed on when I tried to open the
file. The problem was that Lucid's PATHNAME function was treating the
logical name like a device specification instead of expanding it.
TRUENAME would have expanded the logical name for me, but since
LISP$LIBRARY was not a complete pathname for an existing file, it
would also have signalled an error.
I know of no Common Lisp implementation for VMS that doesn't have this
problem. It's a strange thing about VMS that foo: sometimes implies
a directory and sometimes doesn't, and there's no syntactic way to tell.
I think your suggested extension to TRUENAME is a reasonable way to
cope with this oddity of VMS, and perhaps similar oddities of other
operating systems (although I can't think of any right now). How about
writing it up as a proposal?
∂07-Sep-88 1956 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 19:56:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 455983; Wed 7-Sep-88 22:52:31 EDT
Date: Wed, 7 Sep 88 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880831192150.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880908025215.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is too complicated for me. I think it's better to do nothing
until/unless the compiler committee comes up with a better framework
in which to deal with this.
∂07-Sep-88 2005 CL-Cleanup-mailer symbol-macrolet-semantics, symbol-macrolet-utility
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 7 Sep 88 20:05:22 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA07394; Wed, 7 Sep 88 23:05:14 EDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
Barry Margolin <barmar@Think.COM>,
cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
Cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
<8806222146.AA21530@decwrl.dec.com>,
<8806281758.AA10391@decwrl.dec.com>,
<880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<8806291818.AA11107@mist.UUCP>,
<19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
<19880729021542.8.BARMAR@OCCAM.THINK.COM>,
<8807292109.AA03546@decwrl.dec.com>,
<880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-Id: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-Fold: No
I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand. 10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.
I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.
∂07-Sep-88 2004 Common-Lisp-Object-System-mailer symbol-macrolet-semantics, symbol-macrolet-utility
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 20:04:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456000; Wed 7-Sep-88 23:03:21 EDT
Date: Wed, 7 Sep 88 23:03 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: symbol-macrolet-semantics, symbol-macrolet-utility
To: Gregor.pa@Xerox.COM, Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>,
Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>,
Barry Margolin <barmar@Think.COM>, cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
cc: Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU,
Jeffrey Piazza <"piazza%lisp.DEC@decwrl.dec.com"@MULTIMAX.ARPA>
In-Reply-To: <871123130424.8.GREGOR@SPIFF.parc.xerox.com>,
<8806222146.AA21530@decwrl.dec.com>,
<8806281758.AA10391@decwrl.dec.com>,
<880628165306.6.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<8806291818.AA11107@mist.UUCP>,
<19880629204455.4.GREGOR@PORTNOY.parc.xerox.com>,
<19880729021542.8.BARMAR@OCCAM.THINK.COM>,
<8807292109.AA03546@decwrl.dec.com>,
<880801135717.1.KMP@PEWEE.SCRC.Symbolics.COM>
Message-ID: <19880908030301.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I thought it was already well-established that symbol-macrolet has to
be a special form, not a macro, and has to affect the behavior of
macroexpand. 10 months ago I argued that symbol-macrolet didn't
have to be a special form, but I was quite wrong.
I favor the proposal SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM except
for the part about forbidding use of symbol macros with SETQ
(and macros such as MULTIPLE-VALUE-SETQ and PSETQ that presumably
expand into SETQ), which I think is an unnecessary incompatible
change.
∂07-Sep-88 2027 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Sep 88 20:27:26 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456024; Wed 7-Sep-88 23:26:17 EDT
Date: Wed, 7 Sep 88 23:26 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SUBTYPEP-TOO-VAGUE, version 2
To: Sandra J Loosemore <sandra%cdr@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8807192041.AA00292@cdr.utah.edu>
Message-ID: <19880908032600.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I am mostly in favor of SUBTYPEP-TOO-VAGUE:CLARIFY, but have a few
suggestions:
(1) Clarify that SUBTYPEP is allowed to return a second value of NIL
only when either of the type specifiers involves the SATISFIES, MEMBER,
NOT, AND, OR, the list form of FUNCTION, or VALUES type specifiers.
VALUES and the list form of FUNCTION are not valid arguments to SUBTYPEP
(p.72 says the arguments to SUBTYPEP have to be valid for TYPEP, p.47 says
the list form of FUNCTION is invalid for TYPEP, p.48 says VALUES isn't
really a type-specifer [sic] at all). So you can strike those two from
the list.
I'm a little unhappy about excluding MEMBER. I think you should exclude
MEMBER only when it's the second argument and the first argument is not
MEMBER. MEMBER as the first argument is a useful and easy to compute
case: it's just the conjunction of a bunch of calls to TYPEP.
I think if an implementation defines a new type with a name not in CLtL,
the implementation should be permitted to add that type to the list of
types that SUBTYPEP doesn't understand.
The behavior of SUBTYPEP on types defined by DEFSTRUCT and DEFCLASS
should be fully specified. Require it to be the obvious behavior.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
I think it's likely to be complex enough that it needs to be another
proposal. Perhaps acceptance of this proposal will make that one easier
to write, since you can define the behavior in terms of SUBTYPEP.
Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
The former. Fortunately the only difficult cases are COMPLEX, ARRAY and
its subtypes, and numerical ranges. Just to make matters worse, I
believe there is a proposal on the table to change the ARRAY rules. I
forget the issue name.
If you don't think numerical ranges are non-obvious, what is
(subtypep '(single-float 0.0 (1.0))
`(single-float 0.0 ,(- 1.0 single-float-epsilon)))
SCL returns NIL T, which is wrong since these two type specifiers
denote identical finite sets. Once you think you know the answer to that,
translate the example into rationals, replacing (- 1.0 single-float-epsilon)
with a rational that is so close to 1 that any rational that was
closer could not be represented in the implementation because you
would run out of memory! I think the answer to that is that for floats
there is a concept of the next value, and hence a translation from
exclusive to inclusive ranges, but for non-integer rationals there is not.
I can't predict the mathematical implications of this, though.
∂07-Sep-88 2241 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
To: CL-Cleanup@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
I have a minor nit to pick with the writeup for this issue. It says:
``Adoption Cost:
None, since making use of FUNCTION declarations is "optional".''
This isn't true because for us it means hooking up the RESTRICTIVE-FTYPE
mechanism to the FTYPE declaration. I object to the reasoning that
says that because making use of something (by implementations, I presume)
is optional, there is no adoption cost for any changes to it. For example,
making use of any declarations but SPECIAL is optional, so any incompatible
change to those type declarations would be a no-cost-for-adoption change.
Let's say that the cost of adoption is insignificant becaue the only two
implementations that do something with FTYPE declarations can be easily
changed to conform.
An alternative worth considering is to say that
(proclaim '(ftype (function (type1 ... typen) val-type) f))
means:
if arg1,...,argn are of types type1,...,typen, then
(f arg1 ... argn)
is of type val-type.
This provides a means of describing polymorphic functions and
with some added verbiage to obtain even stricter interpretation.
The conditional is impossible to state in a useful way otherwise,
and the polymorphic form has some use for CLOS generic functions
and also arithmetic functions.
-rpg-
∂08-Sep-88 1143 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88 11:43:41 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456357; Thu 8-Sep-88 14:42:06 EDT
Date: Thu, 8 Sep 88 14:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Supersedes: <880908144035.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <880908144147.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 7 Sep 88 22:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
I think that's more consistent with the rest of Common Lisp.
I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P,
ADJUSTABLE-ARRAY-P, BOTH-CASE-P, LOWER-CASE-P, UPPER-CASE-P,
ALPHA-CHAR-P, DIGIT-CHAR-P, GRAPHIC-CHAR-P, STANDARD-CHAR-P and
SPECIAL-FORM-P.
Only ARRAY-IN-BOUNDS-P appears not to fit into this pattern, and
arguably because the embedded modifier is a prepositional phrase
and not a simple adjective.
I'm ignoring COMPILED-FUNCTION-P, RANDOM-STATE-P, HASH-TABLE-P,
SIMPLE-VECTOR-P, BIT-VECTOR-P, SIMPLE-BIT-VECTOR-P, SIMPLE-STRING-P,
and STRING-CHAR-P even though they would support my case because
they are really more a hyphenated-type with "-P" appended than
something with three morphemes.
Am I missing something or doesn't this making a compelling case
that WILD-PATHNAME-P is a better name?
∂08-Sep-88 1143 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88 11:43:42 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456355; Thu 8-Sep-88 14:40:59 EDT
Date: Thu, 8 Sep 88 14:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908021721.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908144035.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 7 Sep 88 22:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
I think that's more consistent with the rest of Common Lisp.
I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P,
ADJUSTABLE-ARRAY-P, BOTH-CASE-P, LOWER-CASE-P, UPPER-CASE-P,
ALPHA-CHAR-P, DIGIT-CHAR-P, GRAPHIC-CHAR-P, STANDARD-CHAR-P,
SPECIAL-FORM-P, and YES-OR-NO-P.
Only ARRAY-IN-BOUNDS-P appears not to fit into this pattern, and
arguably because the embedded modifier is a prepositional phrase
and not a simple adjective.
I'm ignoring COMPILED-FUNCTION-P, RANDOM-STATE-P, HASH-TABLE-P,
SIMPLE-VECTOR-P, BIT-VECTOR-P, SIMPLE-BIT-VECTOR-P, SIMPLE-STRING-P,
and STRING-CHAR-P even though they would support my case because
they are really more a hyphenated-type with "-P" appended than
something with three morphemes.
Am I missing something or doesn't this making a compelling case
that WILD-PATHNAME-P is a better name?
∂08-Sep-88 1147 CL-Cleanup-mailer Issue: PROCLAIM-SCOPE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88 11:47:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 456361; 8 Sep 88 14:46:09 EDT
Date: Thu, 8 Sep 88 14:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-SCOPE (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908025215.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908144549.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 7 Sep 88 22:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This is too complicated for me. I think it's better to do nothing
until/unless the compiler committee comes up with a better framework
in which to deal with this.
This is a reasonable position. Fyi, I do not plan to push this issue
unless someone else gets on the bandwagon with me. I did think it
important to raise it, though, and I think it should at least be one
of the items mentioned in the new manual's list of "things that should
be expected to vary between implementations".
∂08-Sep-88 1254 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88 12:53:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 456425; Thu 8-Sep-88 15:52:20 EDT
Date: Thu, 8 Sep 88 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880908144147.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880908195203.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 8 Sep 88 14:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Wed, 7 Sep 88 22:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I am in favor of PATHNAME-WILD:NEW-FUNCTION with one change.
The function name should be PATHNAME-WILD-P rather than WILD-PATHNAME-P;
I think that's more consistent with the rest of Common Lisp.
I chose modifier-noun-P because of INPUT-STREAM-P, OUTPUT-STREAM-P....
Am I missing something or doesn't this making a compelling case
that WILD-PATHNAME-P is a better name?
To me PATHNAME-WILD-P is analogous to PATHNAME-DIRECTORY. It sounds
like you are thinking of "wild pathname" as a data type whereas I am
thinking of "wildness" as a conceptual slot of a pathname. CL is
sufficiently inconsistent that we can both find justification. Neither
case is compelling and I don't have a strong opinion, although I still
lean to my original position.
∂08-Sep-88 1346 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 1)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 8 Sep 88 13:46:41 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 280437; Thu 8-Sep-88 16:06:49 EDT
Date: Thu, 8 Sep 88 16:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880908195203.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880908160726.3.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Indeed, just as most people probably think of INPUT-STREAM-P as
partitioning types (rather than accessing a slot), I think the
same of PATHNAME-WILD-P.
I don't have strong moral opposition to positioning it as
a conceptual slot, but then I'd want to call it PATHNAME-WILD
rather than PATHNAME-WILD-P. (I'd also wonder why there was
no :WILD or :WILD-P argument to MAKE-PATHNAME, and I might make
some really awful proposal to fix that... :-)
So I'm gonna leave it alone (unless there's a lot of other
opposition).
∂08-Sep-88 1634 CL-Cleanup-mailer Re: Issue: PATHNAME-WILD (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 8 Sep 88 16:34:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 08 SEP 88 15:03:14 PDT
Date: 8 Sep 88 15:03 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-WILD (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Thu, 8 Sep 88 16:07 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880908-150314-1255@Xerox>
Why don't you add to the discussion something like
"We considered the name PATHNAME-WILD-P instead, which is favored by some
members of the cleanup committee. Precedent for both PATHNAME-WILD-P and
WILD-PATHNAME-P (and PATHNAME-WILD) can be found in Common Lisp."
∂12-Sep-88 1147 CL-Cleanup-mailer Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 11:47:38 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457741; Mon 12-Sep-88 14:46:44 EDT
Date: Mon, 12 Sep 88 14:45 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912144559.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION
Edit history: 12-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
DESCRIBE is not prohibited from behaving interactively. In some
implementations it is, and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Clarify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
[Descriptive information would continue to go to *STANDARD-OUTPUT*.]
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This implements the status quo.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
This proposal is the minimal proposal for compatibility with current
behavior. If anyone is adamant about wanting DESCRIBE not to require
user intervention, they might want to circulate a competing proposal
requesting an incompatible change prohibiting current behavior in some
implementations.
∂12-Sep-88 1334 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 13:34:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA12724; Mon, 12 Sep 88 13:33:02 PDT
Message-Id: <8809122033.AA12724@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:21
To: cl-cleanup@sail.stanford.edu
Subject: Issue: IN-PACKAGE-FUNCTIONALITY
This looks OK to me.
∂12-Sep-88 1337 CL-Cleanup-mailer Issue: LAMBDA-FORM
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 13:37:05 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA12854; Mon, 12 Sep 88 13:35:48 PDT
Message-Id: <8809122035.AA12854@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:31
To: cl-cleanup@sail.stanford.edu
Subject: Issue: LAMBDA-FORM
Ideally I'd prefer LAMBDA as a special form and changing some "redundant"
special forms to be macros.
But in the interest of minimizing not-too-consequential changes, I'll
support LAMBDA-FORM:NEW-MACRO.
∂12-Sep-88 1341 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 13:41:49 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13054; Mon, 12 Sep 88 13:40:33 PDT
Message-Id: <8809122040.AA13054@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:35
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-COMPOSITION
This looks OK to me.
Many years ago I suggested we drop -IF-NOT and :TEST-NOT by adding
the proposed COMPLEMENT and supporting the read-macro "#~".
So (FIND-IF-NOT #'ZEROP '(0 0 3)) would be the same as
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3)) would be the same as
(FIND-IF #~ZEROP '(0 0 3))
∂12-Sep-88 1345 CL-Cleanup-mailer Issue: NTH-VALUE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 13:45:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13298; Mon, 12 Sep 88 13:44:22 PDT
Message-Id: <8809122044.AA13298@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:06
To: cl-cleanup@sail.stanford.edu
Subject: Issue: NTH-VALUE
Although technically this proposal looks OK with me, I think it doesn't
offer increased functionality or potential efficiency. It does offer
an easier to read (and write!) interface for getting a multiple value
out of many, but this should be easy to construct as a portable macro.
Since we have so many other proposals which to me seem much more
important, I'd prefer that we not submit this to X3J13 as a whole.
---Walter
∂12-Sep-88 1353 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 13:53:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA13944; Mon, 12 Sep 88 13:52:12 PDT
Message-Id: <8809122052.AA13944@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:49
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
Yes.
I'd be in favor of requiring errors to be signalled, but this isn't too
important to me.
∂12-Sep-88 1417 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Sep 88 14:17:15 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 12 SEP 88 13:54:59 PDT
Date: 12 Sep 88 13:52 PDT
From: Masinter.pa@Xerox.COM
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 12 Sep 88 14:45 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912-135459-1531@Xerox>
I think having DESCRIBE in the standard is much less useful if it is too vague.
If you want something interactive, use INSPECT. No?
∂12-Sep-88 1418 CL-Cleanup-mailer Issue: BOGUS-FIXNUMS
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 14:18:24 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15705; Mon, 12 Sep 88 14:17:02 PDT
Message-Id: <8809122117.AA15705@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:39
To: cl-cleanup@sail.stanford.edu
Subject: Issue: BOGUS-FIXNUMS
Is there still a proposal here? If so, could someone (Sandra?!) update
the proposal to address all the concerns brought out in the mail.
There's too much there for me to assimilate in one sitting.
Thanks ---Walter
PS Actually, maybe every ought to be updating their proposals so we can
cut down on the work Larry has to do and so that we can get as many
proposals ready in time for the next meeting.
PPS When/where is the next cleanup subcommittee meeting? I'd prefer
Monday morning early, to avoid conflict with the editorial mtg, but
such a time might be difficult for people on west-coast time.
∂12-Sep-88 1421 CL-Cleanup-mailer Issue: VARIABLE-LIST-ASYMMETRY
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 12 Sep 88 14:20:59 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15913; Mon, 12 Sep 88 14:19:34 PDT
Message-Id: <8809122119.AA15913@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
Date: 12 Sep 88 16:47
To: cl-cleanup@sail.stanford.edu
Subject: Issue: VARIABLE-LIST-ASYMMETRY
I'll support this. I'll bet most implementations allow LET and LET*
singleton lists, but that it's quite split for DO and DO*.
∂12-Sep-88 1424 CL-Cleanup-mailer issue TRUENAME-SYNTAX-ONLY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 12 Sep 88 14:24:43 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA12089; Mon, 12 Sep 88 15:23:32 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA18137; Mon, 12 Sep 88 15:23:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809122123.AA18137@defun.utah.edu>
Date: Mon, 12 Sep 88 15:23:28 MDT
Subject: issue TRUENAME-SYNTAX-ONLY
To: cl-cleanup@sail.stanford.edu
Here, at Moon's suggestion, is a formal proposal on something I
brought up earlier in connection with issue PATHNAME-SYNTAX-ERROR-TIME.
It is a separate issue since it can stand on its own regardless of which
(if any) of the proposals for PATHNAME-SYNTAX-ERROR-TIME is adopted, but
with a slight modification it could also supplant thos proposals and "fix"
the same problem.
-Sandra
Issue: TRUENAME-SYNTAX-ONLY
References: CLtL p. 413-414
Issue PATHNAME-SYNTAX-ERROR-TIME
Category: ENHANCEMENT, CLARIFICATION
Edit History: V1, Sandra Loosemore, 12 Sep 1988
Problem Description:
Filename syntax under VMS does not provide a syntactic distinction
between device names and logical names which may include other
pathname components. This causes particular problems when a pathname
including a logical name is passed to MERGE-PATHNAMES, since the
implementation may or may not expand the logical name to find the
"hidden" pathname components it includes. Although the function
TRUENAME performs file-name translation, as currently defined it can
only be used for this purpose if the pathname is a complete file
specification for an existing file, since it will signal an error
otherwise.
Other operating systems may have similar problems. For example, some
Lisps which run under Unix (notably PSL) use shell variables or
environment variables to serve the same purpose as logical names under
VMS.
Proposal TRUENAME-SYNTAX-ONLY:ADD:
(1) Add a keyword argument :SYNTAX-ONLY to the function TRUENAME. If
this argument is NIL or not supplied, an error is signalled if an
appropriate file cannot be located within the file systm for the given
pathname. Otherwise, TRUENAME signals an error only if the pathname
has illegal syntax for its specified host; it may not signal an error
if the file does not exist, if the pathname is not a complete file
specification, or if an attempt to create the file would fail for some
other reason (such as a nonexistent directory). TRUENAME applies any
file-name translations performed by the file system and returns the
"true name" of the specified file as a pathname.
(2) Clarify that functions OPEN, RENAME-FILE, DELETE-FILE, PROBE-FILE,
FILE-WRITE-DATE, FILE-AUTHOR, LOAD, and DIRECTORY perform the same
syntax-checking and file-name translation on their arguments as
TRUENAME.
(3) Clarify that coercion of a stream to a pathname (either implicitly
or by a call to the function PATHNAME) returns a pathname representing
the "true name" of the file. However, neither implicit nor explicit
coercion of strings to pathnames causes file-name translation to be
performed.
(4) Clarify that file-name translation on pathnames is not performed
under any other circumstances except those listed above.
Rationale:
This proposal gives the user explicit control over when logical names
are expanded. Other alternatives would be to require translation to
be performed automatically at pathname coercion time or within
MERGE-PATHNAMES. Both of these alternatives are unsatisfactory
because correct translation of the logical name depends on the host
and may not be performed correctly on a partial pathname.
Current Practice:
Vax Lisp under VMS expands logical names by default. (In
MERGE-PATHNAMES? I no longer have access to this implementation.)
Lucid Common Lisp does not, and provides no mechanism for expanding
logical names.
Cost to implementors:
Minor. VMS provides an RMS system call to perform the necessary
translation and syntax checking; this is also performed by default by
the system call which opens a file. Implementations running under
file systems which do not support any concept of logical names need
only perform a syntax check on the pathname within TRUENAME.
Cost to users:
None. This is a compatible change.
Benefits:
A portable mechanism for dealing with logical names is provided.
Discussion:
This proposal leaves open the possibility that syntax errors in
pathnames might also be detected at other times, such as at pathname
coercion time (see issue PATHNAME-SYNTAX-ERROR-TIME). However, it
would also be reasonable to restrict checking for syntax errors to the
same places that file name translation is applied.
-------
∂12-Sep-88 1507 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 15:07:22 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457897; Mon 12-Sep-88 18:06:25 EDT
Date: Mon, 12 Sep 88 18:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880912180516.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Issue: ROOM-DEFAULT-ARGUMENT
References: ROOM (p442)
Category: ADDITION
Edit history: 12-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Passing no argument to ROOM is not equivalent to any argument which
can be passed. This makes data-flow from another function which wants
to call ROOM inconvenient. Rather than simply passing a value through,
the correct calling sequence must be selected as well. For example,
one might have to do something like
(CASE FLAG
(:DEFAULT (ROOM))
((T NIL) (ROOM FLAG)))
where (ROOM FLAG) would suffice
Proposal (ROOM-DEFAULT-ARGUMENT:NEW-VALUE):
Specify that passing an argument of :DEFAULT is equivalent to passing
no argument to ROOM.
Test Case:
(ROOM :DEFAULT) is functionally equivalent to (ROOM).
Rationale:
Minimal change needed to get around the stated problem.
Allows ROOM to be describable without reference to supplied-p
information.
Current Practice:
Symbolics Genera defines ROOM using &REST and looks for NIL, (T), or (NIL).
[This reduces its ability to do compile-time number-of-argument checking.]
Some other implementations probably have a magic undocumented value
to avoid use of a SUPPLIED-P argument.
Cost to Implementors:
Probably it involves negligible resources to change this.
In most implementations, the resulting code would probably look better.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
The description of ROOM will look yucky in the emerging specification.
The source code for ROOM will look yucky.
[How's that for objective? -kmp]
Error checking in some implementations may be sub-optimal.
Benefits:
The description of ROOM in the now-being-written specification would
be less complicated.
Aesthetics:
This proposal would make a minor improvement in aesthetics.
Discussion:
This is obviously a low-priority issue, but would require such little
resources to fix that it seems worth doing.
Pitman supports this addition.
It's perhaps too bad that keywords like :SHORT, :MEDIUM, and :LONG
weren't chosen instead of T and NIL, since T and NIL have a bit of a
binary feel to them and it's hard to think of a good name for the
default case.
∂12-Sep-88 1706 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 17:03:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457978; Mon 12-Sep-88 20:02:25 EDT
Date: Mon, 12 Sep 88 20:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880912180516.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880913000129.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
ROOM-DEFAULT-ARGUMENT:NEW-VALUE is okay, but can't we just get
rid of ROOM entirely? I think it never should have been adopted
from Zetalisp into Common Lisp in the first place.
∂12-Sep-88 1709 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 17:09:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457986; Mon 12-Sep-88 20:08:10 EDT
Date: Mon, 12 Sep 88 20:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: Masinter.pa@Xerox.COM
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880912-135459-1531@Xerox>
Message-ID: <19880913000720.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 12 Sep 88 13:52 PDT
From: Masinter.pa@Xerox.COM
I think having DESCRIBE in the standard is much less useful if it is too vague.
If you want something interactive, use INSPECT. No?
In spite of the name of his proposal, I think Kent was proposing to make
it (slightly) -less- vague. Right now about all CLtL says is that
DESCRIBE prints "information" that is indented. Since the output of
DESCRIBE cannot be useful to programs, I think it's better to allow it
to ask questions than to add a bunch of new mechanism, such as keyword
arguments to DESCRIBE, to control what is printed. Of course a good
implementation would only ask questions when *STANDARD-OUTPUT* is an
interactive stream, if Common Lisp had a way to ask whether a stream is
interactive.
∂12-Sep-88 1727 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 17:27:05 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 457999; Mon 12-Sep-88 20:26:15 EDT
Date: Mon, 12 Sep 88 20:25 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <19880913002519.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: HASH-TABLE-KEY-MODIFICATION
References: CLtL page 282, page 168 (last paragraph in 10.2)
Category: CLARIFICATION
Edit history: Version 1, 12-Sep-88, Moon, for discussion
Problem description:
CLtL is silent about what happens if you modify a component of an object
that is used as a hash-table key.
Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.
In EQUAL hash tables, it is an error to modify a component of a key.
If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function. If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.
Test Cases/Examples:
(setq ht (make-hash-table :test #'eq))
(setq a (cons 1 2))
(setf (gethash a ht) 'win)
(setf (cdr a) 3)
(gethash a ht 'lose) => win t
The same example with :test #'equal in the first line would be an
error.
The following example is not an error, because EQUAL does not examine
the components of general vectors:
(setq ht (make-hash-table :test #'equal))
(setq a (vector 1 2))
(setf (gethash a ht) 'win)
(setf (aref a 1) 3)
(gethash a ht 'lose) => win t
Rationale:
EQ and EQL hash tables use the identity of the object as the key, while
EQUAL hash tables use the structure of the object as the key. Component
modification changes the structure of an object, while the identity of
an object cannot be changed in Common Lisp.
Making component modification of a key of an EQUAL hash table be an error,
rather than requiring it to signal an error, requiring the table to behave
like ASSOC :TEST #'EQUAL, or requiring SETF of GETHASH to copy the key so
that the table is not affected, minimizes the impact on implementations.
This is a generalization of the warning on p.168 of CLtL.
Note that this proposal implies that it is invalid to use an overly
general hash function, such as SXHASH, as the hash function for EQ or
EQL hash tables. The value of SXHASH can be affected by component
modifications, and this is likely to cause hash table entries to become
inaccessible.
Current practice:
I am not aware of any implementations that do not conform to the proposal.
Cost to Implementors:
Most implementations probably already conform. It is possible that some
implementations might have to use a different hash function in their
implementation of some hash tables in order to conform.
Cost to Users:
None.
Cost of non-adoption:
Users would not be sure whether they were allowed to perform side effects
on objects that might have been used as keys of hash tables.
Benefits:
More specific language semantics.
Esthetics:
More specific language semantics.
Discussion:
Discussion on the Common-Lisp mailing list was in favor of this.
∂12-Sep-88 1747 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 17:47:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458005; Mon 12-Sep-88 20:43:49 EDT
Date: Mon, 12 Sep 88 20:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Gregor.pa@Xerox.COM, David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <edsel!dussud@labrea.stanford.edu>,
kempf@Sun.COM, Glenn Andrew Kramer <GAK@SPAR-20.SPAR.SLB.COM>, common-lisp-object-system@SAIL.STANFORD.EDU,
Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
In-Reply-To: <19880802205147.3.GREGOR@PORTNOY.parc.xerox.com>,
<2795614606-3753982@Kelvin>,
<8808031719.AA12130@rainbow-warrior.lucid.com>,
<8808031847.AA18770@suntana.sun.com>,
<2795636967-5097451@Kelvin>,
<GAK.12419581321.BABYL@SPAR-20.SPAR.SLB.COM>,
<8808041525.AA20536@suntana.sun.com>,
<2795711083-4281424@Kelvin>,
<19880808171852.6.GREGOR@PORTNOY.parc.xerox.com>,
<8808111506.AA11766@suntana.sun.com>
Message-ID: <19880913004248.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Issue: SYMBOL-MACROLET-DECLARE
References: SYMBOL-MACROLET (88-002R page 2-81)
WITH-ACCESSORS (88-002R page 2-88)
WITH-SLOTS (88-002R page 2-92)
Category: ADDITION
Edit history: Version 1, 12-Sep-88, Moon
Problem description:
It would be both natural and nice to be able to write
(with-slots (rho theta) point
(declare (single-float rho theta))
...computation...)
Proposal (SYMBOL-MACROLET-DECLARE:ALLOW):
Allow declarations at the head of the body of SYMBOL-MACROLET, and hence
in WITH-ACCESSORS and WITH-SLOTS. Exactly the same declarations are
allowed as for LET, with one exception: SYMBOL-MACROLET signals an error
if a SPECIAL declaration names one of the symbols being defined as a
symbol-macrolet. A type declaration of one of these symbols is equivalent
to wrapping a THE expression around the expansion of that symbol.
Test Cases/Examples:
See problem description.
Rationale:
If SYMBOL-MACROLET is intended to resemble LET in syntax, it ought to
allow declarations. When writing a SYMBOL-MACROLET directly, the user
could just as easily write a THE expression instead of a type
declaration. However, when invoking a macro such as WITH-SLOTS that
expands into SYMBOL-MACROLET, the user does not have this option since
the expansion is not supplied explicitly by the user.
Current practice:
SYMBOL-MACROLET was only tentatively added to Common Lisp 3 months ago.
Cost to Implementors:
Less than one man-hour.
Cost to Users:
None.
Cost of non-adoption:
Minor wart in the language.
Benefits:
More consistent language definition.
Esthetics:
More consistent language definition.
Discussion:
None.
∂12-Sep-88 1814 CL-Cleanup-mailer issue TRUENAME-SYNTAX-ONLY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Sep 88 18:14:40 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458019; Mon 12-Sep-88 21:13:23 EDT
Date: Mon, 12 Sep 88 21:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809122123.AA18137@defun.utah.edu>
Message-ID: <19880913011221.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 12 Sep 88 15:23:28 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
TRUENAME-SYNTAX-ONLY:ADD seems generally reasonable, however I have a
few comments to offer. I think the proposal needs to be amended a bit.
TRUENAME [with the :SYNTAX-ONLY option] applies any
file-name translations performed by the file system and returns the
"true name" of the specified file as a pathname.
Should it be left this vague, and specifically defined to be
implementation-dependent, or should some axioms that it must satisfy be
listed? For example, should TRUENAME with and without the :SYNTAX-ONLY
option be required to return the same answer in the case when the latter
does not signal an error? I suspect it may have to be vague (see below).
(3) Clarify that coercion of a stream to a pathname (either implicitly
or by a call to the function PATHNAME) returns a pathname representing
the "true name" of the file.
This directly contradicts the example at the top of CLtL p.414. I think
you should just remove this point.
(4) Clarify that file-name translation on pathnames is not performed
under any other circumstances except those listed above.
I can't figure out what this means operationally, but I suspect that if
I could figure it out, I would disagree with it. I suggest removing this
point, unless you had something specific in mind, in which case I suggest
rewording this point.
What does (TRUENAME <stream> :SYNTAX-ONLY T) mean?
Cost to implementors:
Minor. VMS provides an RMS system call ....
This overlooks the case of implementations that access VMS files via a
network file protocol. The cost to implementors might be near infinite if
the particular network file protocol they are using does not provide any
way to perform this operation. This suggests that the definition of the
:SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
an implementation that always returned its first argument would be valid.
A lot of the Common Lisp file system interface has to be like that.
However, it
would also be reasonable to restrict checking for syntax errors to the
same places that file name translation is applied.
It would be at least as reasonable to argue that checking for syntax
errors is properly done during file name parsing (i.e. conversion from a
string to a pathname object), as with all other Common Lisp syntax.
Perhaps it would be better not to raise that issue in this proposal.
∂13-Sep-88 0232 CL-Cleanup-mailer Re: COERCE-FROM-TYPE and TYPE-OF
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Sep 88 02:32:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 02:30:47 PDT
Date: 13 Sep 88 02:31 PDT
From: masinter.pa@Xerox.COM
Subject: Re: COERCE-FROM-TYPE and TYPE-OF
In-reply-to: your message of Mon, 18 Jul 88 16:55:32 JST
To: Masayuki Ida <ida%cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net>,
cl-cleanup@Sail.stanford.edu, peck@sun.com
Message-ID: <880913-023047-2587@Xerox>
I think we need a cleanup item to redefine TYPE-OF to be basically (CLASS-NAME
(CLASS-OF x)) with perhaps a few exceptions for vectors and arrays.
I agree that "COERCE object to &optional (from (TYPE-OF object))"
makes little sense without such a clarification. Certainly it would make sense
to allow a class as well as a name as the optional "from" argument to COERCE.
I'd like to see a merger of the COERCE-INCOMPLETE and COERCE-FROM-TYPE issues
into a single one.
A sample implementation of a conformal COERCE (which resorted to some built-in
primitives for data structure conversion) would be useful addition to the
proposal.
Volunteers?
This issue has been in the "pipe" too long. I'd like to see it ready in the next
couple of weeks. So sooner rather than later.
∂13-Sep-88 0633 CL-Cleanup-mailer Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 06:33:03 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA23000; Tue, 13 Sep 88 06:31:47 PDT
Date: Tue, 13 Sep 88 06:31:47 PDT
Message-Id: <8809131331.AA23000@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
I'll support this proposal.
I see another complication regarding the #S syntax in the interaction
between the constructor(s) that have been defined and whether the
structures print out with #S or with #<. I could imagine having
instances of a parent structure printing with #< but wanting to have
instances of a child print with #S. But I don't think this complication
is too important.
---Walter
∂13-Sep-88 0637 CL-Cleanup-mailer Issue: DEFSTRUCT-REDEFINITION
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 06:37:46 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA23237; Tue, 13 Sep 88 06:36:30 PDT
Date: Tue, 13 Sep 88 06:36:30 PDT
Message-Id: <8809131336.AA23237@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DEFSTRUCT-REDEFINITION
Although I tend towards the ideas in DEFSTRUCT-REDEFINITION:ERROR-IFF-OLD-USE,
perhaps people would be a little more comfortable if implementations were
encouraged not to treat an "exact" redefinition as an error (either at
definition time or at access time).
There are several references to the proposal alternative ERROR-IFF-USE
rather than ERROR-IFF-OLD-USE.
---Walter
∂13-Sep-88 0649 CL-Cleanup-mailer Issue PROCLAIM-SCOPE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 06:49:04 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA23595; Tue, 13 Sep 88 06:47:49 PDT
Date: Tue, 13 Sep 88 06:47:49 PDT
Message-Id: <8809131347.AA23595@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue PROCLAIM-SCOPE
I believe adding an option controlling the scope/extent of PROCLAIM would
be confusing--it's simpler to think of PROCLAIM as only being global. It
would be better to have a separate, specific mechanism to handle "file-local"
things, unless a more general mechanism could be devised.
It's probably worth noting that some things are already "file-local", such
as the binding of *PACKAGE*.
Also, VAX LISP has added some keywords to COMPILE-FILE which are file local,
such as :OPTIMIZE.
A last comment: adding a way of querying for PROCLAIMed information might
avoid the issue by leaving it to the user to manipulate explicitly.
---Walter
∂13-Sep-88 0703 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:03:08 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24506; Tue, 13 Sep 88 07:01:53 PDT
Date: Tue, 13 Sep 88 07:01:53 PDT
Message-Id: <8809131401.AA24506@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: LIST-TYPE-SPECIFIER
Actually, I'd prefer exchanging the proposed type names, so that
(LIST *) could be abbreviated as (LIST) could be abbreviated as LIST,
just as for arrays, and with the same meaning regarding element types.
There's still the issue of what specialized list or array type specifiers
means. Assuming the proposal regarding array element type upgrading
(what's the latest on this, btw?) I could see specialized LIST type
specifiers in the same way, with the automatic upgrading of the element
type to T in all (!?) current implementations.
Do we need another cleanup issue on whether (ARRAY foo) implies
(TYPEP (AREF x i) 'foo), just as this issue specifies?
---Walter
∂13-Sep-88 0713 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:13:11 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25377; Tue, 13 Sep 88 07:11:55 PDT
Date: Tue, 13 Sep 88 07:11:55 PDT
Message-Id: <8809131411.AA25377@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED
This looks OK to me.
I think leaving the values of the debugging and module constructs open
to implementation specification is best for allowing experimentation
and growth.
---Walter
∂13-Sep-88 0714 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:14:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA25596; Tue, 13 Sep 88 07:13:23 PDT
Date: Tue, 13 Sep 88 07:13:23 PDT
Message-Id: <8809131413.AA25596@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARGUMENTS-UNDERSPECIFIED
This looks OK to me too, except that version 2 has an incomplete
"Current Practice" section.
∂13-Sep-88 0708 Common-Lisp-Object-System-mailer RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:08:47 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24481; Tue, 13 Sep 88 07:06:10 PDT
Date: Tue, 13 Sep 88 07:06:10 PDT
Message-Id: <8809131406.AA24481@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: SYMBOL-MACROLET-DECLARE (version 1)
This seems like a reasonable proposal and does make SYMBOL-MACROLET more
consistent with LET.
This may be a separate issue, but somewhere we should nail down the
interpretation of e.g.
(symbol-macrolet ((foo bar))
...
(locally (declare (special foo))
...foo...))
As currently specified, only a new binding for FOO can turn off its
interpretation as a symbol macro. I'd like to see some language that said that
a SPECIAL declaration also shadows the symbol macro scope.
The limit case, which your proposal makes "an error", might then reasonably
have a null semantics:
(symbol-macrolet ((foo bar))
(declare (special foo))
...)
might be interpreted as
(locally (declare (special foo))
...)
I don't have strong feelings one way or the other about this part--it doesn't
seem possible to bring SYMBOL-MACROLET into complete consistency with LET here.
/JEP
∂13-Sep-88 0725 CL-Cleanup-mailer Re: COERCE-FROM-TYPE and TYPE-OF
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 07:25:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458237; Tue 13-Sep-88 10:23:15 EDT
Date: Tue, 13 Sep 88 10:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: COERCE-FROM-TYPE and TYPE-OF
To: masinter.pa@Xerox.COM
cc: Masayuki Ida <ida%cc.aoyama.junet%UTOKYO-RELAY.CSNet@relay.cs.net>, cl-cleanup@SAIL.STANFORD.EDU,
peck@sun.com
In-Reply-To: <880913-023047-2587@Xerox>
Message-ID: <19880913142219.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 13 Sep 88 02:31 PDT
From: masinter.pa@Xerox.COM
I think we need a cleanup item to redefine TYPE-OF to be basically (CLASS-NAME
(CLASS-OF x)) with perhaps a few exceptions for vectors and arrays.
I don't entirely agree. CLASS-OF (88-002R pp.1-15 through 1-17) was
carefully defined to require the existence only of built-in classes
on which it is clearly meaningful to put methods in portable programs.
TYPE-OF (CLtL p.53) on the other hand is defined to be for debugging,
not for type-dispatching, and to return as specific an answer as
"convenient and useful." Thus it seems unlikely that people would
really want these two to return the same answer, since they exist for
different purposes.
Also 88-002R (chapter 2) says CLASS-NAME can return NIL.
I would certainly oppose redefining CLASS-OF to have as vague a
definition as TYPE-OF.
If it's proposed to redefine TYPE-OF to be no more specific than
CLASS-OF, I would counter-propose to eliminate TYPE-OF entirely,
since it would be redundant.
∂13-Sep-88 0825 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 08:25:09 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA28994; Tue, 13 Sep 88 08:23:51 PDT
Date: Tue, 13 Sep 88 08:23:51 PDT
Message-Id: <8809131523.AA28994@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
References: CLtL pp 47-48, 158-159
Category: CHANGE
Edit history: #1, 7 Sept 1988, Walter van Roggen
#2, 13 Sept 1988, Walter van Roggen (costs & proposal limitations)
Problem description:
The current description of the specialized FUNCTION type specifier is not very
useful to program analysis tools and is not very intuitive to programmers
because the meaning of the argument type specifiers is not restrictive.
Programmers find it useful to add information about the types of the arguments
a function expects and about the type(s) that a function may return. This
information is useful both to human readers of the code as well as to type
checking programs such as compilers and cross referencers. The only apparent
(but false) way of providing this information is with the FTYPE declaration and
FUNCTION type specifier.
Furthermore, implementations may wish to provide additional optimizations based
on avoiding type checking or different methods of argument passing. These
optimizations require the same sort of information about the argument types.
However, the current definition of FUNCTION type specifiers on pages 47-48 of
CLtL states that a function such as CONS that is of type
(FUNCTION (T T) CONS)
is also of type
(FUNCTION (FLOAT STRING) LIST).
Unfortunately this information is not useful for the above mentioned purposes.
The problem is that the argument types aren't restrictive, so no interesting
matching of types is possible.
Another way of looking at the problem is that specialized FUNCTION type
specifiers cannot be used in a meaningful way for discrimination (as the second
arg to TYPEP, nor as the first argument to THE). Furthermore functions are
assumed not to be sufficiently self-descriptive that a specialized FUNCTION
type is possible to be known or can be constructed when a function is passed to
TYPE-OF.
Thus unlike all the other type declarations, which can be used for
discrimination and have an implicit effect on representation, specialized
FUNCTION type specifiers appear to have superfluous information. By changing
the meaning of the argument types to convey additional descriptive information
instead of behavioral information, we can also satisfy the other needs listed
above.
Proposal (FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE)
For specialized FUNCTION type specifiers
(proclaim '(ftype (function (arg0-type arg1-type ...) val-type) f))
implies
(the val-type (f (the arg0-type ...) (the arg1-type ...) ...))
If the arguments to F are of the specified types, then the result will be of
the specified type. If the arguments do not all match the specified types, it
is an error, and then the result is not guaranteed to be of the specified type.
This proposal does not alter the status (or lack thereof) of other issues
related to FUNCTION type specifiers: what lambda-list keywords mean, what the
VALUES type means, what implications there are w.r.t. argument counts, doing
multiple PROCLAIMs, doing local DECLAREs that shadow other declarations or
proclamations, describing generic functions incrementally, the result of TYPEP
with a specialized FUNCTION type.
Rationale:
The proposal seems most like what users expect.
Current Practice:
VAX LISP already assumes and makes use of the "restrictive" semantics. Lucid
has a RESTRICTIVE-FTYPE declaration with these semantics and ignores the
standard FTYPE declaration. Gold Hill intends to use these declarations in this
manner. Many implementations don't make use of these declarations. At least
several users make use of declarations assuming the new semantics.
Cost to Implementors:
Since most implementations don't make use of function declarations, and since
those known to do so can be changed easily, the cost should be minimal.
Cost to Users:
There may be some existing "imprecise" function declarations. However, the
natural tendency when providing these declarations is to be as "descriptive"
(i.e., restrictive but complete) as possible, both for documentation purposes
as well as for potential compiler benefits. There cannot have been any uses of
the specialized FUNCTION type for discrimination. Thus most existing uses are
probably compatible with this new definition.
Cost of Non-Adoption:
There already exists user code on many implementations that assume the
proposed semantics. Not adopting this proposal would continue to render
such code incorrect or at least non-portable.
Benefits:
Better type checking and more compiler optimizations should be possible.
Esthetics:
This is the what most programmers expect the specialized FUNCTION type to
mean, particularly those coming from other languages.
Discussion:
∂13-Sep-88 0916 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Sep 88 09:16:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA01115; Tue, 13 Sep 88 10:14:56 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA18524; Tue, 13 Sep 88 10:14:48 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809131614.AA18524@defun.utah.edu>
Date: Tue, 13 Sep 88 10:14:47 MDT
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 12 Sep 88 21:12 EDT
> Date: Mon, 12 Sep 88 21:12 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> TRUENAME [with the :SYNTAX-ONLY option] applies any
> file-name translations performed by the file system and returns the
> "true name" of the specified file as a pathname.
>
> Should it be left this vague, and specifically defined to be
> implementation-dependent, or should some axioms that it must satisfy be
> listed? For example, should TRUENAME with and without the :SYNTAX-ONLY
> option be required to return the same answer in the case when the latter
> does not signal an error? I suspect it may have to be vague (see below).
The language in CLtL is already vague, but as far as I know nobody has
been complaining about it. At least for VMS, I'd say that TRUENAME
shouldn't have to return the same answer in both cases; the reason is
that if you don't supply an explicit version number in the input
pathname and you tell TRUENAME to match an existing file, it ought to
fill in the version number for that file; but if you're only checking
syntax it doesn't have any way of knowing what the version number
should be.
> (3) Clarify that coercion of a stream to a pathname (either implicitly
> or by a call to the function PATHNAME) returns a pathname representing
> the "true name" of the file.
>
> This directly contradicts the example at the top of CLtL p.414. I think
> you should just remove this point.
Sorry, "clarify" was the wrong word here. Except for the example you
cite, CLtL doesn't explicitly address the issue of what coercing a
stream to a pathname really does. The idea is, that since OPEN must
perform the equivalent of TRUENAME anyway, it can just as well create
a stream that remembers the "true name" of the file as the pathname
that was passed to OPEN. As I recall, VaxLisp already behaves as
proposed. However, if people would prefer it that way, I could change
this item to leave this behavior explicitly vague.
> (4) Clarify that file-name translation on pathnames is not performed
> under any other circumstances except those listed above.
>
> I can't figure out what this means operationally, but I suspect that if
> I could figure it out, I would disagree with it. I suggest removing this
> point, unless you had something specific in mind, in which case I suggest
> rewording this point.
What I had in mind was that none of the zillion other pathname
functions (which I was too lazy to list) would be allowed to do file
name translation; nor would coercing a string to a pathname. For
example, (pathname-device "foo:bar.baz") on VMS would always return
"foo", even if it's defined as a logical name.
> Cost to implementors:
>
> Minor. VMS provides an RMS system call ....
>
> This overlooks the case of implementations that access VMS files via a
> network file protocol. The cost to implementors might be near infinite if
> the particular network file protocol they are using does not provide any
> way to perform this operation. This suggests that the definition of the
> :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
> an implementation that always returned its first argument would be valid.
> A lot of the Common Lisp file system interface has to be like that.
That's a good point -- I'd forgotten about networking from non-VMS
hosts. However, if an implementation doesn't expand logical names
fully when requested to do so, users are going to run into the same
kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
me to bring this up in the first place. I don't see much point in
adding this functionality to the language unless the spec is tight
enough to ensure that it's going to solve the problem it was intended
to.
> It would be at least as reasonable to argue that checking for syntax
> errors is properly done during file name parsing (i.e. conversion from a
> string to a pathname object), as with all other Common Lisp syntax.
Yes, of course. However, it's possible to construct pathnames which
might contain "syntax errors" by other means as well. For instance, if
you merge pathnames from two different hosts you might end up with
subfields that are too long, illegal characters, etc.
-Sandra
-------
∂13-Sep-88 0935 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 09:35:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458341; Tue 13-Sep-88 12:33:18 EDT
Date: Tue, 13 Sep 88 12:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880913000720.7.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<880912-135459-1531@Xerox>
Message-ID: <880913123225.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 12 Sep 88 20:07 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: 12 Sep 88 13:52 PDT
From: Masinter.pa@Xerox.COM
I think having DESCRIBE in the standard is much less useful if it is too vague.
If you want something interactive, use INSPECT. No?
In spite of the name of his proposal, I think Kent was proposing to make
it (slightly) -less- vague. ...
Right. It's already vague. I was proposing to make that vagueness apparent
so it wouldn't be a time bomb in some people's code.
A few more thoughts for what they're worth...
- CLtL (and Kathy's current draft manual) describes INSPECT as an interactive
version of DESCRIBE. That doesn't quite contractually oblige DESCRIBE to be
non-interactive, but it does provide an interesting perspective on intent.
- Another way to go is to provide an argument saying whether it was ok
to ask questions:
DESCRIBE thing &OPTIONAL (query-ok (INTERACTIVE-STREAM-P *STANDARD-OUTPUT*))
where QUERY-OK would default according to the interactiveness of the
stream in question
or
DESCRIBE thing &KEY (verbose :QUERY)
where VERBOSE might be one of T, NIL, or :QUERY
- If people are going to be writing CLOS methods for DESCRIBE, we better get
started early in saying whether they ought to be incorporating queries into
their code. [Interestingly, though, the CLOS spec requires the methods for
DESCRIBE to be compatible with CLtL's description of DESCRIBE, not the
emerging ANSI spec's description. :-]
∂13-Sep-88 1109 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:09:45 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458411; Tue 13-Sep-88 14:07:28 EDT
Date: Tue, 13 Sep 88 14:06 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <19880908013813.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880913140645.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 7 Sep 88 21:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 5 Sep 88 17:51:08 BST
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
5. Symbol-macro-flet: SYMBOL-MACRO-LET lets me have something that
looks like a variable but is really some expression. It might seem
that MACROLET does the same for function names, but it doesn't.
MACROLET applies to entire calls, not just the name. This suggests
that SYMBOL-MACRO-LET should have a companion, SYMBOL-MACRO-FLET.
This is Zetalisp's "lambda macros", also available in Symbolics Common
Lisp. They're called that because they let users write new things that
behave like LAMBDA. ...
I don't think what Jeff's talking about is lambda macros. There are currently
really three possibilities:
(... symbol ...)
(symbol ...)
((symbol ...) ...)
Lambda macros are about the third of these. My impression is that Jeff's
talking about the second. For example, in the Cloe implementation of Flavors,
the implementation of DEFUN-IN-FLAVOR uses a macro which we call
SYMBOL-FMACROLET. That lets
(DEFUN-IN-FLAVOR (F FOO) ...)
(DEFMETHOD (ZAP FOO) () (F X))
[effectively] expand into
(DEFUN |F in FOO| ...)
(DEFMETHOD (ZAP FOO) () (|F in FOO| ...))
by going through an intermediate step such as:
(DEFMETHOD (ZAP FOO) ()
(SYMBOL-FMACROLET ((F |F in FOO|))
(F X)))
This facility, which I think is the one Jeff is alluding to, is very
different from what lambda macros are for.
Aside: As far as I've been able to discern, DEFUN-IN-FLAVOR has very little
place in CLOS so this example may seem a bit foreign to people not familiar
with Flavors. Sorry about that.
Regardless of the merits of DEFUN-IN-FLAVOR, I think Jeff's right that
this companion special form (SYMBOL-FMACROLET or SYMBOL-MACRO-FLET or
SYMBOL-MACROFLET or whatever) is interesting. Also, for the sake of a
portable implementation of New Flavors and things like it, I think it
would make very good sense to consider adding it now rather than waiting
until we realize we're screwed without it. SYMBOL-MACROFLET is as hard
to write as a macro as SYMBOL-MACROLET, so if you think SYMBOL-MACROLET
really must be a special form, then I argue that so should
SYMBOL-MACROFLET.
∂13-Sep-88 1131 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:31:40 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00199g; Tue, 13 Sep 88 10:29:42 PST
Received: from blacksox.lucid.com by edsel id AA06153g; Tue, 13 Sep 88 11:24:24 PDT
Received: by blacksox id AA00321g; Tue, 13 Sep 88 11:27:10 pdt
Date: Tue, 13 Sep 88 11:27:10 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131827.AA00321@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 14:06 EDT <880913140645.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
Doesn't this do what you want?
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(macrolet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
`(,',(second renaming) ,@args)))
renamings)
,@body))
∂13-Sep-88 1145 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 11:45:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA00217g; Tue, 13 Sep 88 10:43:38 PST
Received: by rainbow-warrior id AA03013g; Tue, 13 Sep 88 11:41:59 PDT
Date: Tue, 13 Sep 88 11:41:59 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809131841.AA03013@rainbow-warrior>
To: piazza%lisp.DEC@decwrl.dec.com
Cc: Moon@stony-brook.scrc.symbolics.com,
Common-Lisp-Object-System@SAIL.STANFORD.EDU,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Jeffrey Piazza's message of Tue, 13 Sep 88 07:06:10 PDT <8809131406.AA24481@decwrl.dec.com>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Date: Tue, 13 Sep 88 07:06:10 PDT
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
This seems like a reasonable proposal and does make SYMBOL-MACROLET more
consistent with LET.
This may be a separate issue, but somewhere we should nail down the
interpretation of e.g.
(symbol-macrolet ((foo bar))
...
(locally (declare (special foo))
...foo...))
As currently specified, only a new binding for FOO can turn off its
interpretation as a symbol macro. I'd like to see some language that said that
a SPECIAL declaration also shadows the symbol macro scope.
That seems reasonable.
The limit case, which your proposal makes "an error", might then reasonably
have a null semantics:
(symbol-macrolet ((foo bar))
(declare (special foo))
...)
might be interpreted as
(locally (declare (special foo))
...)
This would be a very bad idea, it would be very inconsistent with LET, and
would introduce a bizarre semantics: Throw away what I just said in the
binding list. I think that it should be an error.
Patrick.
∂13-Sep-88 1212 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:12:21 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458465; Tue 13-Sep-88 15:06:32 EDT
Date: Tue, 13 Sep 88 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809131827.AA00321@blacksox.lucid.com>
Message-ID: <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 11:27:10 pdt
From: Eric Benson <eb@lucid.com>
Doesn't this do what you want?
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(macrolet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
`(,',(second renaming) ,@args)))
renamings)
,@body))
No: think about #' .
In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
able to do (MAPCAR #'local-function things) rather than
(MAPCAR #'method-name (CIRCULAR-LIST SELF) things).
∂13-Sep-88 1213 CL-Cleanup-mailer Exponent sign printing with ~E
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:13:24 PDT
Received: from KRYPTON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458477; Tue 13-Sep-88 15:12:33 EDT
Date: Tue, 13 Sep 88 15:11 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Exponent sign printing with ~E
To: CL-CLeanup@Sail.stanford.edu, Cassels@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <870703-173352-132@Xerox>
Message-ID: <19880913191142.7.CASSELS@KRYPTON.SCRC.Symbolics.COM>
Issue: ~E-EXPONENT-SIGN
References: CLtL pp. 366, 393
Category: CLARIFICATION
Edit history: Bob Cassels, 13 Sep 88
Related issues: <none>
Problem description:
The result of (format nil "~E" 1.0) is specified in a contradictory way.
The ambiguity is whether a plus sign should be printed in front of
the exponent.
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
So the posssibilities are:
A. "1.0e+0"
B. "1.0e0"
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
Proposal (~E-EXPONENT-SIGN:FORCE-SIGN):
Change the wording on page 393 to:
"If all of w, d, and e are omitted, then the effect is to print the
value using ordinary free-format exponential-notation output; PRIN1 uses
a similar format for any non-zero number whose magnitude is less than
10**-3 or greater than or equal to 10**7. The only difference is that
the ~E directive always prints a plus or minus sign in front of the
exponent, while PRIN1 omits the plus sign if the exponent is
non-negative."
Test Case:
(format nil "~E" 1.0) => "1.0e+0"
Rationale:
This proposal makes ~E self-consistent. That is more important than
making ~E consistent with PRIN1.
Current practice:
Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
sign as in the test case above. Apollo DOMAIN Common Lisp (version
2.10) produces "1.0", which is simply wrong.
Adoption Cost:
Minimal changes to one printing routine for non-conforming
implementations. (No change to the three implementations mentioned
above.)
Cost of non-adoption:
Minor confusion and possible incompatibility among implementations.
Benefits:
Less confusion, more compatibility.
Conversion Cost:
Minimal. It is doubtful that any user programs depend on this
obscure distinction.
Esthetics:
A matter of opinion.
Discussion:
Fortran ~E format requires a sign before the exponent, since the exponent
mark character may be dropped. Since Common Lisp ~E always prints
the exponent marker, the exponent sign may be dropped in the case
that it would be a plus sign.
∂13-Sep-88 1214 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:14:13 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00266g; Tue, 13 Sep 88 11:12:48 PST
Received: from blacksox.lucid.com by edsel id AA06258g; Tue, 13 Sep 88 12:07:28 PDT
Received: by blacksox id AA00332g; Tue, 13 Sep 88 12:09:15 pdt
Date: Tue, 13 Sep 88 12:09:15 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131909.AA00332@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 15:05 EDT <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
Date: Tue, 13 Sep 88 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 11:27:10 pdt
From: Eric Benson <eb@lucid.com>
Doesn't this do what you want?
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(macrolet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
`(,',(second renaming) ,@args)))
renamings)
,@body))
No: think about #' .
In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
able to do (MAPCAR #'local-function things) rather than
(MAPCAR #'method-name (CIRCULAR-LIST SELF) things).
This will work:
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(flet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
`(apply #',',(second renaming) args)))
renamings)
(declare (inline ,@(mapcar #'first renamings)))
,@body))
Of course you won't be happy with
∂13-Sep-88 1216 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:16:48 PDT
Received: from edsel ([192.9.200.1]) by heavens-gate.lucid.com id AA00275g; Tue, 13 Sep 88 11:15:23 PST
Received: from blacksox.lucid.com by edsel id AA06262g; Tue, 13 Sep 88 12:10:00 PDT
Received: by blacksox id AA00335g; Tue, 13 Sep 88 12:12:45 pdt
Date: Tue, 13 Sep 88 12:12:45 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809131912.AA00335@blacksox.lucid.com>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 15:05 EDT <880913150548.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
Date: Tue, 13 Sep 88 15:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 11:27:10 pdt
From: Eric Benson <eb@lucid.com>
Doesn't this do what you want?
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(macrolet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
`(,',(second renaming) ,@args)))
renamings)
,@body))
No: think about #' .
In my experience, a common reason to use DEFUN-IN-FLAVOR (rather than
DEFMETHOD) is to make the name suitable for MAPCAR. That is, to be
able to do (MAPCAR #'local-function things) rather than
(MAPCAR #'method-name (CIRCULAR-LIST SELF) things).
Sorry about the premature posting; my fingers slipped.
This will work:
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(flet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
(apply #',(second renaming) args)))
renamings)
(declare (inline ,@(mapcar #'first renamings)))
,@body))
Of course you won't be happy with the result unless your compiler
optimizes (APPLY x (LIST a b c)) into (FUNCALL x a b c).
∂13-Sep-88 1232 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:32:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14068; Tue, 13 Sep 88 12:30:52 PDT
Date: Tue, 13 Sep 88 12:30:52 PDT
Message-Id: <8809131930.AA14068@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-ACCESS (version 1)
Issue: HASH-TABLE-ACCESS
References: hash-tables (Chapter 21 of CLtL)
Category: ADDITION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
There are many characteristics of hash-tables which are specified upon
creation but are not accessible afterwards.
Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be either EQL or #'EQL.
Current Practice:
VAX LISP implements the proposal.
Cost to Implementors:
Most of these should be trivial to implement, since the information
must be present for nearly all types.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
The benefits would not be available in a portable fashion.
Benefits:
Programs would be able to access useful information otherwise hidden.
For example, it would allow programs to gain statistics about hash
table usage that might enable better tuning.
Discussion:
None of these are required to be SETF'able, though that might be
a reasonable implementation-dependent extension.
This first appeared in ">GLS>clarifications.text" of 12/06/85.
∂13-Sep-88 1234 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:33:53 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14180; Tue, 13 Sep 88 12:32:37 PDT
Date: Tue, 13 Sep 88 12:32:37 PDT
Message-Id: <8809131932.AA14180@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (version 1)
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
CLtL isn't clear on what may be in the body of a TAGBODY.
Proposal: (TAGBODY-CONTENTS:RESTRICT)
Anything in a TAGBODY other than a tag (a symbol or an integer) or
a list is an error.
It is an error for the same (EQL) tag to appear more than once in the
body of a TAGBODY. (However, a TAGBODY may have the same tag as
another TAGBODY in which it nests, in which case the tag in the outer
TAGBODY is shadowed, as already specified.)
The same restrictions apply to all forms which implicitly use TAGBODY,
such as PROG and DO.
Current Practice:
Cost to Implementors:
A few simple checks are probably all that's needed, and probably
most implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code. If there are implementations which
support other objects as tags (floats, for example), there may be simple
editing necessary.
Benefits:
A slightly more precise description of the language.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
∂13-Sep-88 1238 CL-Cleanup-mailer Issue: TAILP-NIL (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:38:22 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA14339; Tue, 13 Sep 88 12:37:02 PDT
Date: Tue, 13 Sep 88 12:37:02 PDT
Message-Id: <8809131937.AA14339@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAILP-NIL (version 1)
Issue: TAILP-NIL
References: TAILP (p 275 of CLtL)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sept-88, version 1 by Walter van Roggen
Problem Description:
CLtL, in the description of TAILP, states:
(TAILP sublist list)
"is true if (NTHCDR n list) is sublist, for some value of n. See
LDIFF."
However, the behavior when sublist is NIL is not what was intended,
as implied by the description of LDIFF and a common definition of
TAILP:
(defun tailp (sublist list)
(do ((list list (cdr list)))
((null list) nil)
(if (eq sublist list)
(return t))))
Proposal: (TAILP-NIL:NIL)
(TAILP NIL X) returns NIL for all lists X. Qualify the description
in CLtL by saying that:
(TAILP sublist list)
"is true if (NTHCDR n list) is sublist for some value of n, if sublist
is a non-null list, and is false if sublist is NIL."
Current Practice:
This is probably what all implementations already do.
Cost to Implementors:
An implementation is given in the Problem Description.
Cost to Users:
Unlikely to affect any portable code, due to the Current Practice.
Benefits:
A slightly more precise description of the language.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
∂13-Sep-88 1240 CL-Cleanup-mailer SYMBOL-MACROFLET
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 12:40:15 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458509; Tue 13-Sep-88 15:37:08 EDT
Date: Tue, 13 Sep 88 15:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROFLET
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM,
jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK, Masinter.pa@xerox.com,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <8809131912.AA00335@blacksox.lucid.com>
Message-ID: <880913153624.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 12:12:45 pdt
From: Eric Benson <eb@lucid.com>
This will work:
(defmacro fsymbolf-fmacrofletf (renamings &body body)
`(flet ,(mapcar #'(lambda (renaming)
`(,(first renaming) (&rest args)
(apply #',(second renaming) args)))
renamings)
(declare (inline ,@(mapcar #'first renamings)))
,@body))
Of course you won't be happy with the result unless your compiler
optimizes (APPLY x (LIST a b c)) into (FUNCALL x a b c).
Ours happens to do that optimization, but not everyone's does so it's
bad to rely on that for portable code, which is actually what I was
thinking about. If I was only worried about our own implementations, we
could just have our own private implementation of fsymbolf-fmacrofletf
and be done with it.
Also, INLINE is not required to be processed by everyone, so there's
another place you might take a runtime speed hit.
Also, some compilers complain when you don't use the function. So you
have to put #'name1 #'name2 ... etc. at toplevel in the FLET body.
[But then you have to worry that some compilers won't remove that.]
Anyway, we used to do DEFUN-IN-FLAVOR by using FLET, but the practical
fact is that all the smarts needed to make FLET work can be a big drain
on the compiler. If you write zillions of DEFUN-IN-FLAVORs (which some
people do), then -every- method on that flavor (whether it uses the
function or not) must have this enormous FLET in it just so that the
compiler can optimize it out. It is zillions of times more efficient
at compile time (how's that for an exacting metric?) to use our
SYMBOL-FMACROLET strategy than to use FLET. It forces the compiler to
do semantic analysis only on demand -- which is what you need to make
a thing like this really useful.
(By the way, I -do- like your choice of name. When I finally talk you
into adopting this, I definitely think that fsymbolf-fmacrofletf
will be the icing on the cake. :-)
∂13-Sep-88 1459 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 13 Sep 88 14:59:12 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00771; Tue, 13 Sep 88 17:58:58 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA01990; Tue, 13 Sep 88 18:00:35 EDT
Message-Id: <8809132200.AA01990@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Date: Tue, 13 Sep 88 18:00:34 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Sorry for the delay in this, but I've been waiting for preliminary
comments from an (unnamed) member of this committee...
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Status: For Internal Discussion
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):
Remove the second argument from REQUIRE. Change the description of
REQUIRE to:
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
file.
Change the "Put in seven extremely random user interface commands"
discussion to suggest that PROVIDE should be put at the end of the
file rather than the beginning.
Test Cases/Examples:
(REQUIRE 'fft)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp. However implementations could still
provide this as an extension.
Rationale:
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
Putting PROVIDE at the beginning of a file is a mistake because the
file will still appear to be PROVIDEd if it fails to load. This may
cause files loaded later to fail mysteriously because the first failed
file didn't define expected constants or macros, etc.
Current practice:
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
change.
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
Benefits:
PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
Pierson supports this proposal.
∂13-Sep-88 1502 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 15:02:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458605; Tue 13-Sep-88 18:01:20 EDT
Date: Tue, 13 Sep 88 18:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
To: Masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880904-152018-8868@Xerox>
Message-ID: <880913180032.4.KMP@GRYPHON.SCRC.Symbolics.COM>
I'm happy with most of this but I have one bone to pick.
I believe the END argument to PARSE-INTEGER should be permitted to be
NIL, meaning use the rest of the string. This is most convenient from
an implementation point of view because one can write
&KEY (START 0) (END NIL)
If you say the argument must be an integer, you must write:
&KEY (START 0) (END NIL END-P)
and complain if END is NIL while END-P is T (which seems gratuitous
error checking since the functionality would be useful) or else you must
do
&KEY (START 0) (END (LENGTH STRING))
which is also gratuitous since the function will not be certain that the
value of END is correct and will have to do (LENGTH STRING) yet again in
order to validate the value of END.
I believe an analogous criterion should be applied to END arguments
across the board. If someone thinks it appropriate, I will write this up
as a separate cleanup.
∂13-Sep-88 1542 CL-Cleanup-mailer Issue: TAILP-NIL (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 15:42:23 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458628; Tue 13-Sep-88 18:41:32 EDT
Date: Tue, 13 Sep 88 18:40 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAILP-NIL (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880913184048.5.KMP@GRYPHON.SCRC.Symbolics.COM>
I just can't buy into this. I think it's a big mistake to require a
sublist to be a CONS. It teaches people to confuse the notion of CONS
with the notion of LIST. The latter may include NIL. I have added
another option which I can support.
-----
Issue: TAILP-NIL
References: TAILP (p275)
Category: CLARIFICATION/CHANGE
Edit History: 13-Sep-88, version 1 by Walter van Roggen,
13-Sep-88, version 2 by Pitman
Problem Description:
CLtL (p275) specifies TAILP as:
TAILP sublist list [Function]
This predicate is true if SUBLIST is a sublist of LIST (i.e.,
one of the conses that makes up LIST); otherwise, it is false.
Another way to look at this is that TAILP is true if
(NTHCDR n list) is SUBLIST, for some value of N. See LDIFF.
Two common implementations of this definition are:
(defun tailp (sublist list) ;Definition "A"
(do ((list list (cdr list)))
((endp list) nil)
(if (eq sublist list)
(return t))))
(defun tailp (sublist list) ;Definition "B"
(do ((list list (cdr list)))
((atom list) (eq list sublist))
(if (eq sublist list)
(return t))))
They differ only in their treatment of the atomic case.
At issue is the fact that () is a list, and hence some would
argue that it is a sublist of all other lists. On the other hand,
the definition of TAILP seems to imply that being a cons is a
necessary precondition of being a "sublist".
Proposal (TAILP-NIL:NIL):
Clarify that the sublist argument to TAILP must be a list
and that (TAILP NIL X) returns NIL for all lists X.
Qualify the description in CLtL by saying that (TAILP sublist list)
is true if SUBLIST is a cons and (NTHCDR n list) is SUBLIST for
some value of N, and is false otherwise.
Rationale:
This is the status quo in a number of implementations.
Proposal (TAILP-NIL:T):
Strike any text in the definition of TAILP which suggests that a
sublist must be a cons.
Clarify that (TAILP any-atom list) returns T iff (NTHCDR n list) is
SUBLIST for some value of N, and false otherwise.
Rationale:
This is more consistent with the definition of LDIFF, which
gives a useful meaning to arbitrary atomic SUBLIST arguments.
This gives a more elegant definition of SUBLIST, allowing it to
refer to any list -- including the empty list -- which is a
part of another list.
Test Cases:
#1: (LET ((X '(B C))) (TAILP X (CONS 'A X)))
should return T in all implementations.
#2: (TAILP '(X Y) '(A B C))
should return NIL in all implementations.
#3: (TAILP '() '(A B C))
returns NIL under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#4: (TAILP 3 '(A B C))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
#5: (TAILP 3 '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns T under proposal TAILP-NIL:T
#6: (TAILP '(X Y) '(A B C . 3))
is an error under proposal TAILP-NIL:NIL
returns NIL under proposal TAILP-NIL:T
Current Practice:
Symbolics Genera is consistent with TAILP-NIL:T.
[Walter alleges TAILP-NIL:NIL is what all implementations already
do, but since Genera is not in conformance, KMP regards that
hypothesis as suspect. We need real data points, folks.]
Cost to Implementors:
An implementation of TAILP-NIL:NIL is given as Definition "A" in the
problem description.
An implementation of TAILP-NIL:T is given as Definition "B" in the
problem description.
Some implementations might have compiler optimizers for these definitions
as well, so a slight amount of additional effort might be required.
Cost to Users:
Given that current practice varies widely on the disputed case,
this is unlikely to have a practical effect on existing portable code.
Benefits:
Either description makes the language more precise.
[Pitman believes that] TAILP-NIL:T is more consistent with the behavior
of TAILP and more consistent with what he thinks should be the
definition of a sublist.
Discussion:
This issue was first raised in ">GLS>clarifications.text" of 12/06/85.
Pitman supports TAILP-NIL:T.
∂13-Sep-88 1550 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 15:50:48 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458636; Tue 13-Sep-88 18:49:51 EDT
Date: Tue, 13 Sep 88 18:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
To: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@MULTIMAX.ARPA
In-Reply-To: <8809132200.AA01990@mist.UUCP>
Message-ID: <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>
This is an improvement, but I personally still consider the whole
PROVIDE/REQUIRE feature to be bankrupt for another reason, unrelated
to the file issue. Specifically:
If PROVIDE is at the top of a file, that will make mutually dependent
systems loadable. If it's at the bottom of a file, then mutually
dependent systems will recursively load ad nauseum (or will go back
and forth erring, depending on whether you have Pierson's cleanup).
That would seem to argue for putting PROVIDE at the top. But then, if
a file blows out, you've provided the module already and there is no
provision to have the PROVIDE undone.
Unless we require PROVIDE to cooperate with LOAD and to have the
PROVIDE info persist only if LOAD does a normal
(i.e., non-erring, non-throwing, ...) return would I really believe
in PROVIDE and REQUIRE. I could -really- get behind PROVIDE and REQUIRE
if we could work out the details of this kind of cooperation to everyone's
satisfaction.
I would also buy into a further restriction on PROVIDE and REQUIRE which
said that it was not to be used for mutually dependent systems, and
that PROVIDE was recommended for use only after having actually done
the providing -- not at the head of the set of file(s).
In the absence of those concessions, I agree that Dan's cleanup is
reasonable, but I don't know to what good end. In my opinion, he's
optimizing a still-worthless utility.
∂13-Sep-88 1604 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 16:03:59 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458649; Tue 13-Sep-88 19:02:54 EDT
Date: Tue, 13 Sep 88 19:02 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809131932.AA14180@decwrl.dec.com>
Message-ID: <880913190211.7.KMP@GRYPHON.SCRC.Symbolics.COM>
I generally support this TAGBODY-CONTENTS:RESTRICT, but have the following comments:
Cost to Implementors:
A few simple checks are probably all that's needed, and probably
most implementations (both interpreters and compilers) already perform them.
Actually, this should be "no cost" since you've only said this "is an error".
You've not required implementations to signal. With my portable-code-writer's hat
on, I'd applaud any attempts to make implementations really signal in this case,
but my guess is that most implementors (maybe even Symbolics itself) would boo me
on this and would regard this as an imposition of the same caliber as my IF-BODY
suggestion a while back.
Cost to Users:
Unlikely to affect any portable code. If there are implementations which
support other objects as tags (floats, for example), there may be simple
editing necessary.
Again, no cost. Users already can't rely on anything more than what's in CLtL.
If they do, they're not writing CL code. Further, since you're not forcing
implementations to change, they are free to continue to rely on this non-portable
extension as long as implementors don't get overzealous and upgrade just for grins.
Bottom line: I don't think this proposal really restricts anything. I think it's
just a restatement of the status quo. If you think there's confusion, I accept that
statement as an existence proof that there is confusion and I'm happy to see it
clarified.
∂13-Sep-88 1612 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Sep 88 16:12:00 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458655; Tue 13-Sep-88 19:10:49 EDT
Date: Tue, 13 Sep 88 19:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-CLEANUP@SAIL.Stanford.EDU
In-Reply-To: <8809131930.AA14068@decwrl.dec.com>
Message-ID: <880913191005.8.KMP@GRYPHON.SCRC.Symbolics.COM>
I'll support this, though I would -really- like to see this business of
the test (EQ vs #'EQ) resolved.
Personally, I feel that since the set is non-extensible, we ought to
change it to allow only :EQ, :EQL, or :EQUAL (and permit implementations
to accept other values for compatibility). Then the value returned
by HASH-TABLE-TEST could be deterministically :EQ (or whatever) and
we could do away with the popular Trivial Pursuit (TM) question about
how the test is recognized. I think it would simplify a lot of things.
If people buy this, I will write it up as a separate cleanup item.
∂13-Sep-88 2331 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 13 Sep 88 23:31:39 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09763@EDDIE.MIT.EDU>; Wed, 14 Sep 88 02:30:16 EDT
Received: by spt.entity.com (smail2.5); 14 Sep 88 02:11:45 EDT (Wed)
To: CL-Cleanup@SAIL.Stanford.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, pierson%mist@MULTIMAX.ARPA
In-Reply-To: Kent M Pitman's message of Tue, 13 Sep 88 18:49 EDT <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Message-Id: <8809140211.AA10382@spt.entity.com>
Date: 14 Sep 88 02:11:45 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)
It would be a lot easier for implementations to give PROVIDE/REQUIRE
reasonable semantics if CL wasn't so damn specific about how these functions
must be implemented. As I recall CLtL basically states that PROVIDE must
immediately push the module name onto the user-visible variable *MODULES*,
and REQUIRE must check if the module name is on *MODULES*. This doesn't leave
much room for improvement, in that any divergence from this proscription could
be detected by some theoretical program manipulating/examining *MODULES*
directly.
Coral decided that in practice the mutually dependent systems problem is more
important than strict conformance, so our REQUIRE checks a separately
maintained list of modules being loaded and punts on them even if they're not
on *MODULES*. Nobody has ever complained.
From my point of view, the ideal solution would be for *MODULES* to be removed
from the language, or at least make its relationship to PROVIDE/REQUIRE less
immediate. Then we can talk about what PROVIDE/REQUIRE should do without
worrying about explicit manipulation of *MODULES* by user code.
As long as there is a chance that PROVIDE/REQUIRE could be fixed up, I think
it would be a mistake to state, as this proposal does, that PROVIDE should
appear at the bottom of the file. Much of the descriptive power of PROVIDE is
lost if you have to put it (and hence the module name) out of view. It's
certainly easy enough for implementations to achive the desired effect
regardless of where the provide happens to physically occur (if only provide
wasn't specified in terms of immediate effects on *modules*), so why put the
burden on the user.
∂14-Sep-88 0007 CL-Cleanup-mailer Re: Exponent sign printing with ~E
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 00:07:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 SEP 88 23:59:47 PDT
Date: 14 Sep 88 00:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Exponent sign printing with ~E
In-reply-to: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>'s
message of Tue, 13 Sep 88 15:11 EDT
To: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-CLeanup@Sail.stanford.edu
Message-ID: <880913-235947-1036@Xerox>
To make my filing system happier, I'm going to rename this issue FORMAT-E-EXPONENT-SIGN.
∂14-Sep-88 0123 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 01:23:47 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 01:20:05 PDT
Date: 14 Sep 88 01:20 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
In-reply-to: gz@spt.entity.com (Gail Zacharias)'s message of 14 Sep 88 02:11:45
EDT (Wed)
To: gz@spt.entity.com (Gail Zacharias)
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
pierson%mist@MULTIMAX.ARPA
Message-ID: <880914-012005-1082@Xerox>
What I remember from a subcommittee meeting (that only included a small subset
of the people on the mailing list, unfortunately) is that we informally agreed
to do something of the sort; that is, to remove any operative definition of
PROVIDE and REQUIRE. The exact wording is tricky.
The issue I think is whether we think that programs that have recursive
requirements should be portable. I think so -- it is consistent with current
practice and the users issue.
I wonder if part of the way of handling this is to be more explicit about what
we all know: that LOAD, PROVIDE and REQUIRE have to cooperate to make this work
right.
∂14-Sep-88 0244 CL-Cleanup-mailer Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 02:44:28 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 02:43:10 PDT
Date: 14 Sep 88 02:43 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECODE-UNIVERSAL-DAYLIGHT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 20 Jun 88 17:09 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-024310-1128@Xerox>
There's been no discussion on this issue since last June.
The wording "If {\arg time-zone\/} is not specified, the current time zone is
used." seems to me to be justification to say that leaving the time zone out is
the same as supplying it.
The Xerox implementor assumed LIKE-ENCODE also.
I'd like a few more words explaining that the test case only is useful when
daylight savings is in effect (or else supplying constant values that are known
to be in the daylight savings time range.)
I think test cases can either be 'automatic' -- you can just run them, but they
take a while to figure out, or 'explanatory' -- they illustrate the point. This
one isn't either yet.
∂14-Sep-88 0635 CL-Cleanup-mailer RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 06:35:16 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00316; Wed, 14 Sep 88 06:33:39 PDT
Date: Wed, 14 Sep 88 06:33:39 PDT
Message-Id: <8809141333.AA00316@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: ARGUMENTS-UNDERSPECIFIED (Version 2)
Allowing END to be NIL across the board is a good idea. However,
the current PARSE-INTEGER doesn't say NIL is supposed to mean anything,
so I think this would be a change in the functionality. So another
cleanup item would be appropriate. You might want to generalize and
talk about the uses of all the normal "sequence" keyword arguments.
For example, I don't think CLtL says that the predicates and :key's
may get called any number of times in any order, except when describing
SEARCH. I think that should be stated for all the sequence functions.
---Walter
∂14-Sep-88 0651 CL-Cleanup-mailer RE: Issue: TAILP-NIL (Version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 06:51:25 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA00737; Wed, 14 Sep 88 06:49:27 PDT
Date: Wed, 14 Sep 88 06:49:27 PDT
Message-Id: <8809141349.AA00737@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: TAILP-NIL (Version 2)
Well, that's a surprise. I thought I had spotted a simple, non-controversial
item from Guy's list, which really needed to be done due to the inconsistency
in CLtL.
I must admit that I hadn't tried TAILP on a Symbolics machine. I had just
read the description of TAILP in an older manual, which gave the possible
implementation I originally included (definition "A"). I guess I was guilty
of propagating false concepts.
Frankly, I don't really care which way we choose. If several other would
prefer TAILP-NIL:T, then let's delete the TAILP-NIL:NIL proposal. But
let's not spend a lot of time on it.
---Walter
∂14-Sep-88 0721 CL-Cleanup-mailer RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 07:21:29 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA02973; Wed, 14 Sep 88 07:20:09 PDT
Date: Wed, 14 Sep 88 07:20:09 PDT
Message-Id: <8809141420.AA02973@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: pierson%mist@multimax.arpa
Subject: RE: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
This looks pretty good, except I think many implementations would
prefer not to have a requirement that *TERMINAL-IO* be a Common Lisp
stream. Already most implementations bind *TERMINAL-IO* to
implementation dependent streams, and I think in this case it's
best to continue the status quo. Another way to look at this issue
is that I don't see any advantage to forcing *TERMINAL-IO* to
be yet another synonym stream or a two-way-stream (or whatever CL
stream type) which really just uses the implementation dependent
stream after all.
---Walter
∂14-Sep-88 0730 CL-Cleanup-mailer Issue: STREAM-CAPABILITIES
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 07:30:33 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03471; Wed, 14 Sep 88 07:29:16 PDT
Date: Wed, 14 Sep 88 07:29:16 PDT
Message-Id: <8809141429.AA03471@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: STREAM-CAPABILITIES
I think I mostly agree with Larry that STREAM-SAME-xxx-P (or STREAM-xxx-
ID-LIST) aren't needed. His reasons aren't clear from the write-up;
I believe that such functionality would be nice but too difficult to
provide in some implementations and therefore shouldn't be part of
the language. For example, what happens with streams working on
remote files?
---Walter
∂14-Sep-88 0748 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 07:48:10 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA04055; Wed, 14 Sep 88 07:46:51 PDT
Date: Wed, 14 Sep 88 07:46:51 PDT
Message-Id: <8809141446.AA04055@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: PACKAGE-CLUTTER
I think this issue also needs to address the default value for :USEd
packages. (Or else the name should be changed to something more
specific like LISP-PACKAGE-CONTENTS.)
If we allow the default value for :USE to be implementation dependent,
I think users would be most happy. If someone really wants just Common
Lisp, they would be able to say :USE '("LISP"). Otherwise they would
be able to get the same environment that the USER package has, since
implementations would have the flexibility to make them the same and
as rich as they would like to make them.
I think this is what resulted from those CL discussions a few years ago.
I'd guess that this is also what several implementations do. Anyone
care to comment?
---Walter
∂14-Sep-88 0804 CL-Cleanup-mailer Issue: ALIST-NIL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 08:03:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05199; Wed, 14 Sep 88 08:02:38 PDT
Date: Wed, 14 Sep 88 08:02:38 PDT
Message-Id: <8809141502.AA05199@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ALIST-NIL
I've put out an open query of our internal users to see if anyone
actually uses this "feature". I'd like to support the proposal
ALIST-NIL:DISALLOW.
Another reason for adopting this change is that the xASSOCx functions
would typically be faster in many implementations, since they wouldn't
have to explicitly check for atoms or NIL's. Since association lists
are often heavily used, the proposal would also have a positive impact
on performance.
---Walter
∂14-Sep-88 0924 CL-Cleanup-mailer Issue: ALIST-NIL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 09:24:22 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458961; Wed 14-Sep-88 12:22:48 EDT
Date: Wed, 14 Sep 88 12:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809141502.AA05199@decwrl.dec.com>
Message-ID: <19880914162223.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Sep 88 08:02:38 PDT
From: vanroggen%aitg.DEC@decwrl.dec.com
I've put out an open query of our internal users to see if anyone
actually uses this "feature". I'd like to support the proposal
ALIST-NIL:DISALLOW.
Another reason for adopting this change is that the xASSOCx functions
would typically be faster in many implementations, since they wouldn't
have to explicitly check for atoms or NIL's. Since association lists
are often heavily used, the proposal would also have a positive impact
on performance.
To my surprise, we didn't have any trouble implementing this feature
(ASSOC skips over NILs where it expects conses) in hardware in the
Ivory microprocessor. It didn't even slow it down.
This is not to say that I think a less tightly integrated Lisp
implementation would not be slowed down by this feature. Note,
however, that you don't have to check for NIL until after you
think you've found the matching CAAR (assuming you have a typical
implementation where CAR of NIL works with the same open-coded
instructions as CAR of a cons), so the slowdown is not proportional
to the length of the list.
I'm neutral on the cleanup issue.
∂14-Sep-88 0934 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 09:33:56 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458973; Wed 14-Sep-88 12:32:42 EDT
Date: Wed, 14 Sep 88 12:32 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809141446.AA04055@decwrl.dec.com>
Message-ID: <19880914163208.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 14 Sep 88 07:46:51 PDT
From: vanroggen%aitg.DEC@decwrl.dec.com
I think this issue also needs to address the default value for :USEd
packages. (Or else the name should be changed to something more
specific like LISP-PACKAGE-CONTENTS.)
If we allow the default value for :USE to be implementation dependent,
I think users would be most happy. If someone really wants just Common
Lisp, they would be able to say :USE '("LISP"). Otherwise they would
be able to get the same environment that the USER package has, since
implementations would have the flexibility to make them the same and
as rich as they would like to make them.
I think this is what resulted from those CL discussions a few years ago.
I'd guess that this is also what several implementations do. Anyone
care to comment?
Symbolics defaults :USE the way CLtL specifies, that is, to just the
LISP package. I'm really not sure that I agree with you that the
default should be changed. A program that wants a specific set of
implementation dependent extensions really ought to ask for them by name
[i.e. (make-package 'foo :use '(gulf-and-western-common-lisp))] so it
can be sure of what it's getting. A program that wants the same
extensions as the user package can do so [i.e. (make-package 'foo
:use (package-use-list (find-package 'user)))].
I'm not sure how much this default matters. I don't think I have ever
seen a defpackage that didn't specify :use explicitly.
∂14-Sep-88 0934 CL-Cleanup-mailer RE: Issue: ALIST-NIL
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 09:33:58 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA09817; Wed, 14 Sep 88 09:32:15 PDT
Date: Wed, 14 Sep 88 09:32:15 PDT
Message-Id: <8809141632.AA09817@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: Moon@stony-brook.scrc.symbolics.com
Subject: RE: Issue: ALIST-NIL
Note,
however, that you don't have to check for NIL until after you
think you've found the matching CAAR (assuming you have a typical
implementation where CAR of NIL works with the same open-coded
instructions as CAR of a cons), so the slowdown is not proportional
to the length of the list.
That's a clever optimization, but I thought it would be improper to
FUNCALL the predicate on an apparent NIL that really isn't in the
association list. But it would work if we special cased the code
if we knew the predicate was innocous, like EQL or EQ.
---Walter
∂14-Sep-88 0944 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 09:44:36 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 458992; Wed 14-Sep-88 12:43:44 EDT
Date: Wed, 14 Sep 88 12:42 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880914124243.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Issue: RANGE-OF-START-AND-END-PARAMETERS
References: COUNT (p257), COUNT-IF (p257), COUNT-IF-NOT (p257),
DELETE (p257), DELETE-DUPLICATES (p254), DELETE-IF (p254),
DELETE-IF-NOT (p254), FILL (p252), FIND (p257), FIND-IF (p257),
FIND-IF-NOT (p257), MAKE-STRING-INPUT-STREAM (p330),
MISMATCH (p257), NSTRING-CAPITALIZE (p304),
NSTRING-DOWNCASE (p304), NSTRING-UPCASE (p304), SUBSTITUTE (p255),
NSUBSTITUTE-IF (p256), NSUBSTITUTE-IF-NOT (p256),
PARSE-INTEGER (p381), PARSE-NAMESTRING (p414), POSITION (p257),
POSITION-IF (p257), POSITION-IF-NOT (p257),
READ-FROM-STRING (p381), REDUCE (p251), REMOVE (p253),
REMOVE-DUPLICATES (p254), REMOVE-IF (p253), REMOVE-IF-NOT (p253),
REPLACE (p252), SEARCH (p258), STRING-CAPITALIZE (p303),
STRING-EQUAL (p301), STRING-DOWNCASE (p303), STRING-GREATERP (p302),
STRING-LESSP (p302), STRING-NOT-EQUAL (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-UPCASE (p303), STRING/= (p301), STRING< (p301),
STRING<= (p301), STRING= (p300), STRING> (p301), STRING>= (p301),
SUBSEQ (p248), SUBSTITUTE (p255), SUBSTITUTE-IF (p255),
SUBSTITUTE-IF-NOT (p255), WRITE-LINE (p384), WRITE-STRING (p384)
Category: CLARIFICATION
Edit history: 14-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
CLtL is not always clear about the possible values which the START and END
parameters of built-in Common Lisp can take.
Proposal (RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL):
Clarify that for functions permitting a parameter named START, START1,
or START2 which delimits the beginning point in a sequence to be
considered for some operation, that paremeter must be a non-negative
integer. If the argument is optional or key (as is the case for all
functions referenced above except SUBSEQ), the value will default to
0 if not supplied. It is not permissible to pass NIL as this argument.
Clarify that for functions permitting a parameter named END, END1,
or END2 which delimits the end point in a sequence to be considered
for some operation, that paremeter must be a non-negative integer
indicating a termination point or NIL indicating the last element
in the sequence. If the argument is optional or key (as is the case
for all functions referenced above), the value will default to NIL
if not supplied. Supplying NIL is, therefore, equivalent to not
supplying this argument.
Test Case:
(SEARCH "F" "FOO" :START1 NIL) is an error.
(SEARCH "F" "FOO" :START2 0) is permissible and is equivalent to
(SEARCH "F" "FOO")
(SEARCH "F" "FOO" :END2 NIL) is permissible and is equivalent to
(SEARCH "F" "FOO")
Rationale:
To keep data flow between programs from becoming excessively complicated,
it's a good idea to specify what the default values are so that they can
be passed explicitly rather than requiring an alternate calling sequence
for all possible cases where the value might need to default.
Current Practice:
Symbolics Genera implements the proposed behavior.
Cost to Implementors:
Hopefully most implementations already do this. Those that do not will
probably have to make quite a number of small changes to both the code
for these functions and to any associated compiler optimizers.
Cost to Users:
This change is upward compatible with existing user code. Any program
which did not conform to this proposal was already not portable.
Cost of Non-Adoption:
Subtle gratuitous differences in the handling of these arguments would
continue to be a possibility and a barrier to portability.
Benefits:
The language would be more regular and well-defined.
Aesthetics:
If it makes things clearer, it's an improvement.
Discussion:
Pitman supports RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
∂14-Sep-88 1010 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 10:10:39 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459027; Wed 14-Sep-88 13:09:24 EDT
Date: Wed, 14 Sep 88 13:08 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER
To: Moon@STONY-BROOK.SCRC.Symbolics.COM,
vanroggen%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880914163208.0.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<8809141446.AA04055@decwrl.dec.com>
Message-ID: <880914130830.2.KMP@GRYPHON.SCRC.Symbolics.COM>
I don't think the idea of making the default for :USE be implementation
dependent is a very good one. It introduces incompatibility to no good
end.
In Cloe, LISP:IN-PACKAGE defaults to :USE "LISP" but CLOE:IN-PACKAGE
defaults to :USE "CLOE". Since the USER package uses CLOE, doing
(IN-PACKAGE "FOO") in that package is the same as doing
(CLOE:IN-PACKAGE "FOO" :USE "CLOE").
Users must do (LISP:IN-PACKAGE "FOO") if they want the effect of
(LISP:IN-PACKAGE "FOO" :USE "LISP") without specifying an explicit
:USE argument.
Or they can, as various people have recommended in this discussion, do
(IN-PACKAGE "FOO" :USE "LISP"). This will get them package something
that uses "LISP" whether they're getting CLOE:IN-PACKAGE or
LISP:IN-PACKAGE.
This may seem a little complicated, but practical experience shows that
it feels like the right thing. After all, we're not changing the meaning
of LISP symbols, so anyone who requests LISP explicitly gets exactly
what CLtL tells them to expect.
∂14-Sep-88 1020 CL-Cleanup-mailer RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 14 Sep 88 10:20:39 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA12552; Wed, 14 Sep 88 10:19:01 PDT
Date: Wed, 14 Sep 88 10:19:01 PDT
Message-Id: <8809141719.AA12552@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: KMP@stony-brook.scrc.symbolics.com
Subject: RE: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Did anyone write up SUBSEQ-OUT-OF-BOUNDS before? It seems RANGE...
would subsume the SUBSEQ... proposal if it also stated that the END value
had to be greater than or equal to the START, and also be no greater than
the LENGTH of the sequence.
---Walter
∂14-Sep-88 1031 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 10:31:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 10:17:45 PDT
Date: Wed, 14 Sep 88 09:55 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@MULTIMAX.ARPA
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <880913184907.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914165511.9.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
I sure would like to see require and provide removed from the language.
As a maintainer of a portable program, people are always asking me to
"use them". The only thing is that I have never been able to figure out
a way to do that that works in the 14 Common Lisp implementations I know
of. I also can't understand what it could possibly mean for programs
that span multiple files.
-------
∂14-Sep-88 1130 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 11:30:31 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459118; Wed 14-Sep-88 14:29:18 EDT
Date: Wed, 14 Sep 88 14:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880914124243.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914182854.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve RANGE-OF-START-AND-END-PARAMETERS:INTEGER-AND-INTEGER-NIL.
I think it would be good to mention explicitly that an end parameter
must be >= its corresponding start parameter, just to keep things
perfectly clear.
∂14-Sep-88 1226 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 12:25:57 PDT
Received: from Burger.ms by ArpaGateway.ms ; 14 SEP 88 12:08:35 PDT
Date: 14 Sep 88 12:07 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 2)
In-reply-to: Masinter.pa's message of 8 Jun 88 19:16 PDT
To: CL-Cleanup@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <880914-120836-2043@Xerox>
There's been no discussion on this proposal since 8 Jun, when it was distributed
in draft form to X3J13. I am taking this to mean that people are not unhappy
with the version of 23-Mar-88 -- at least not unhappy enough to complain or
suggest improvements.
∂14-Sep-88 1233 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 12:33:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459177; Wed 14-Sep-88 15:31:43 EDT
Date: Wed, 14 Sep 88 15:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131614.AA18524@defun.utah.edu>
Message-ID: <19880914193105.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 10:14:47 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 12 Sep 88 21:12 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> TRUENAME [with the :SYNTAX-ONLY option] applies any
> file-name translations performed by the file system and returns the
> "true name" of the specified file as a pathname.
>
> Should it be left this vague, and specifically defined to be
> implementation-dependent, or should some axioms that it must satisfy be
> listed? For example, should TRUENAME with and without the :SYNTAX-ONLY
> option be required to return the same answer in the case when the latter
> does not signal an error? I suspect it may have to be vague (see below).
The language in CLtL is already vague, but as far as I know nobody has
been complaining about it. At least for VMS, I'd say that TRUENAME
shouldn't have to return the same answer in both cases; the reason is
that if you don't supply an explicit version number in the input
pathname and you tell TRUENAME to match an existing file, it ought to
fill in the version number for that file; but if you're only checking
syntax it doesn't have any way of knowing what the version number
should be.
I see. Okay, let's not try axioms. Now that I read it again, your
description of :SYNTAX-ONLY can't be right, though. It refers to
"the specified file" but you aren't specifying any particular file.
Perhaps this can only be defined in terms of a VAX/VMS example.
Or perhaps it can be defined by saying that where file name components
are missing or wild or :NEWEST or :OLDEST, the :SYNTAX-ONLY option
tells you what's common to the truenames of all possible files with
all possible values for those components, whereas without :SYNTAX-ONLY
you specify a single specific file (after merging with a default)
and get just the truename of that exact file. In fact what I just
said won't work in file systems with links, nor in those with complex
pattern-matching translation mechanisms (ITS has both, for example).
Perhaps you can come up with a better description of what :SYNTAX-ONLY
does? I appear to have struck out.
> (3) Clarify that coercion of a stream to a pathname (either implicitly
> or by a call to the function PATHNAME) returns a pathname representing
> the "true name" of the file.
>
> This directly contradicts the example at the top of CLtL p.414. I think
> you should just remove this point.
Sorry, "clarify" was the wrong word here. Except for the example you
cite, CLtL doesn't explicitly address the issue of what coercing a
stream to a pathname really does. The idea is, that since OPEN must
perform the equivalent of TRUENAME anyway, it can just as well create
a stream that remembers the "true name" of the file as the pathname
that was passed to OPEN. As I recall, VaxLisp already behaves as
proposed. However, if people would prefer it that way, I could change
this item to leave this behavior explicitly vague.
You're proposing that TRUENAME of a stream and PATHNAME of a stream behave
identically. I think CLtL means for PATHNAME of a stream to return the
argument that was given to OPEN (after merging with the default). I'm a
little surprised the Cleanup group haven't addressed this already.
> (4) Clarify that file-name translation on pathnames is not performed
> under any other circumstances except those listed above.
>
> I can't figure out what this means operationally, but I suspect that if
> I could figure it out, I would disagree with it. I suggest removing this
> point, unless you had something specific in mind, in which case I suggest
> rewording this point.
What I had in mind was that none of the zillion other pathname
functions (which I was too lazy to list) would be allowed to do file
name translation; nor would coercing a string to a pathname. For
example, (pathname-device "foo:bar.baz") on VMS would always return
"foo", even if it's defined as a logical name.
I agree with that, but I think it can only be said explicitly, not by
implication from "any other circumstances." For example, does "any other
circumstances" include all implementation extensions and all user-written code?
> Cost to implementors:
>
> Minor. VMS provides an RMS system call ....
>
> This overlooks the case of implementations that access VMS files via a
> network file protocol. The cost to implementors might be near infinite if
> the particular network file protocol they are using does not provide any
> way to perform this operation. This suggests that the definition of the
> :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
> an implementation that always returned its first argument would be valid.
> A lot of the Common Lisp file system interface has to be like that.
That's a good point -- I'd forgotten about networking from non-VMS
hosts. However, if an implementation doesn't expand logical names
fully when requested to do so, users are going to run into the same
kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
me to bring this up in the first place.
Yes, many network file access protocols are very poorly designed. I don't
think X3J13 is going to fix that.
I don't see much point in
adding this functionality to the language unless the spec is tight
enough to ensure that it's going to solve the problem it was intended
to.
That could be a problem, especially if the problem it's intended to solve
can't be precisely articulated in an implementation-independent way.
> It would be at least as reasonable to argue that checking for syntax
> errors is properly done during file name parsing (i.e. conversion from a
> string to a pathname object), as with all other Common Lisp syntax.
Yes, of course. However, it's possible to construct pathnames which
might contain "syntax errors" by other means as well. For instance, if
you merge pathnames from two different hosts you might end up with
subfields that are too long, illegal characters, etc.
I should have said parsing and merging and component setting, i.e. all
forms of pathname construction.
∂14-Sep-88 1321 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88 13:21:20 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106652; Wed 14-Sep-88 15:48:20 EDT
Date: Wed, 14 Sep 88 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-ACCESS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131930.AA14068@decwrl.dec.com>
Message-ID: <19880914194817.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't see anything immediately wrong with this, but I have a vague
recollection that the cleanup committee discussed and rejected a
similar proposal once before. If so, we should find out why.
Could it be that it's not clear precisely what some of these values
mean?
∂14-Sep-88 1322 CL-Cleanup-mailer not about Issue: HASH-TABLE-ACCESS (version 1)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Sep 88 13:21:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 390886; Wed 14-Sep-88 15:46:40 EDT
Date: Wed, 14 Sep 88 15:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: not about Issue: HASH-TABLE-ACCESS (version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: vanroggen%aitg.DEC@decwrl.dec.com, CL-CLEANUP@SAIL.Stanford.EDU
In-Reply-To: <880913191005.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880914194605.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 19:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I'll support this, though I would -really- like to see this business of
the test (EQ vs #'EQ) resolved.
Personally, I feel that since the set is non-extensible, we ought to
change it to allow only :EQ, :EQL, or :EQUAL (and permit implementations
to accept other values for compatibility). Then the value returned
by HASH-TABLE-TEST could be deterministically :EQ (or whatever) and
we could do away with the popular Trivial Pursuit (TM) question about
how the test is recognized. I think it would simplify a lot of things.
If people buy this, I will write it up as a separate cleanup item.
I am strongly opposed to this. It would be horrible for this to be
incompatible with every other :TEST keyword argument in the language.
Also I deny that it is non-extensible. Common Lisp doesn't currently
provide a way to make it extensible, but in fact that is very easy to
add; SCL has it.
∂14-Sep-88 1322 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88 13:22:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106654; Wed 14-Sep-88 15:54:21 EDT
Date: Wed, 14 Sep 88 15:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131614.AA18524@defun.utah.edu>
Supersedes: <19880914193105.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: More information, after delving into KMP's electronic basement on my hands and knees
Message-ID: <19880914195416.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 13 Sep 88 10:14:47 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 12 Sep 88 21:12 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> TRUENAME [with the :SYNTAX-ONLY option] applies any
> file-name translations performed by the file system and returns the
> "true name" of the specified file as a pathname.
>
> Should it be left this vague, and specifically defined to be
> implementation-dependent, or should some axioms that it must satisfy be
> listed? For example, should TRUENAME with and without the :SYNTAX-ONLY
> option be required to return the same answer in the case when the latter
> does not signal an error? I suspect it may have to be vague (see below).
The language in CLtL is already vague, but as far as I know nobody has
been complaining about it. At least for VMS, I'd say that TRUENAME
shouldn't have to return the same answer in both cases; the reason is
that if you don't supply an explicit version number in the input
pathname and you tell TRUENAME to match an existing file, it ought to
fill in the version number for that file; but if you're only checking
syntax it doesn't have any way of knowing what the version number
should be.
I see. Okay, let's not try axioms. Now that I read it again, your
description of :SYNTAX-ONLY can't be right, though. It refers to
"the specified file" but you aren't specifying any particular file.
Perhaps this can only be defined in terms of a VAX/VMS example.
Or perhaps it can be defined by saying that where file name components
are missing or wild or :NEWEST or :OLDEST, the :SYNTAX-ONLY option
tells you what's common to the truenames of all possible files with
all possible values for those components, whereas without :SYNTAX-ONLY
you specify a single specific file (after merging with a default)
and get just the truename of that exact file. In fact what I just
said won't work in file systems with links, nor in those with complex
pattern-matching translation mechanisms (ITS has both, for example).
Perhaps you can come up with a better description of what :SYNTAX-ONLY
does? I appear to have struck out.
> (3) Clarify that coercion of a stream to a pathname (either implicitly
> or by a call to the function PATHNAME) returns a pathname representing
> the "true name" of the file.
>
> This directly contradicts the example at the top of CLtL p.414. I think
> you should just remove this point.
Sorry, "clarify" was the wrong word here. Except for the example you
cite, CLtL doesn't explicitly address the issue of what coercing a
stream to a pathname really does. The idea is, that since OPEN must
perform the equivalent of TRUENAME anyway, it can just as well create
a stream that remembers the "true name" of the file as the pathname
that was passed to OPEN. As I recall, VaxLisp already behaves as
proposed. However, if people would prefer it that way, I could change
this item to leave this behavior explicitly vague.
You're proposing that TRUENAME of a stream and PATHNAME of a stream behave
identically. I think CLtL means for PATHNAME of a stream to return the
argument that was given to OPEN (after merging with the default). I'm a
little surprised the Cleanup group haven't addressed this already.
LATER: Ah, I see they have. Already-accepted issue PATHNAME-STREAM
clarified this, in a way consistent with what I said just above.
> (4) Clarify that file-name translation on pathnames is not performed
> under any other circumstances except those listed above.
>
> I can't figure out what this means operationally, but I suspect that if
> I could figure it out, I would disagree with it. I suggest removing this
> point, unless you had something specific in mind, in which case I suggest
> rewording this point.
What I had in mind was that none of the zillion other pathname
functions (which I was too lazy to list) would be allowed to do file
name translation; nor would coercing a string to a pathname. For
example, (pathname-device "foo:bar.baz") on VMS would always return
"foo", even if it's defined as a logical name.
I agree with that, but I think it can only be said explicitly, not by
implication from "any other circumstances." For example, does "any other
circumstances" include all implementation extensions and all user-written code?
> Cost to implementors:
>
> Minor. VMS provides an RMS system call ....
>
> This overlooks the case of implementations that access VMS files via a
> network file protocol. The cost to implementors might be near infinite if
> the particular network file protocol they are using does not provide any
> way to perform this operation. This suggests that the definition of the
> :SYNTAX-ONLY option to TRUENAME should be left sufficiently vague that
> an implementation that always returned its first argument would be valid.
> A lot of the Common Lisp file system interface has to be like that.
That's a good point -- I'd forgotten about networking from non-VMS
hosts. However, if an implementation doesn't expand logical names
fully when requested to do so, users are going to run into the same
kind of strange behavior (i.e., within MERGE-PATHNAMES) that prompted
me to bring this up in the first place.
Yes, many network file access protocols are very poorly designed. I don't
think X3J13 is going to fix that.
I don't see much point in
adding this functionality to the language unless the spec is tight
enough to ensure that it's going to solve the problem it was intended
to.
That could be a problem, especially if the problem it's intended to solve
can't be precisely articulated in an implementation-independent way.
> It would be at least as reasonable to argue that checking for syntax
> errors is properly done during file name parsing (i.e. conversion from a
> string to a pathname object), as with all other Common Lisp syntax.
Yes, of course. However, it's possible to construct pathnames which
might contain "syntax errors" by other means as well. For instance, if
you merge pathnames from two different hosts you might end up with
subfields that are too long, illegal characters, etc.
I should have said parsing and merging and component setting, i.e. all
forms of pathname construction.
∂14-Sep-88 1329 CL-Cleanup-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 14 Sep 88 13:29:27 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 106665; Wed 14-Sep-88 16:28:05 EDT
Date: Wed, 14 Sep 88 16:27 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
To: CL-Cleanup@sail.stanford.edu
References: <8807200836.AA02976@bhopal.lucid.com>,
<19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
<870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19880914202753.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
References: CLtL p.194
Category: CHANGE
Edit history: Version 1, 14-Sep-88, Moon
Problem description:
The numerical contagion rules specified on CLtL p.194 make it impossible
for the numerical comparison functions to be transitive when given
arguments of mixed floating and rational types (see example below).
Proposal (CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE):
Instead of using the same contagion rule both for combining functions
and for comparing functions, make the present rule apply only to
combining functions and add the following rule: When rational and
floating-point numbers are compared by a numerical function, the
function RATIONAL is called to convert the floating-point number to a
rational and then an exact comparison is performed. In the case of
complex numbers (RATIONAL is for some unknown reason only allowed on
reals), the real and imaginary parts are handled individually.
It is of course valid to use a more efficient implementation than
actually calling RATIONAL, as long as the result of the comparison is
the same.
Test Cases/Examples:
(defvar a (/ 10.0 single-float-epsilon))
(= a (1+ (floor a)))
should be NIL, since
(= a (floor a))
is certainly T and
(= (floor a) (1+ (floor a)))
is certainly NIL. However, by the rule of floating-point contagion,
(= a (1+ (floor a)))
is the same as
(= a (float (1+ (floor a)) a))
and the latter form is certainly T.
To understand this example better, it helps to realize that
(= a (+ a 1.0))
is always true, by the definition of single-float-epsilon.
Here is a second example:
(defvar i (floor a))
(<= a (+ i 1)) is T.
(< (+ i 1) (+ i 2)) is T.
(<= (+ i 2) a) is T by CLtL, NIL by this proposal.
Thus CLtL requires
a <= i+1 < i+2 <= a
which ought to imply
a < a
which is absurd.
Rationale:
Transitivity of = and of < are important to many algorithms. What CLtL
says now was probably not intentional, but just the result of thinking
that comparing and combining could be lumped together without really
thinking about it.
Without this change, it is impossible to extend the :TEST argument to
MAKE-HASH-TABLE to allow = or EQUALP, since there could be two table
entries with rational keys that are not =, then GETHASH could be
presented with a floating-point argument that is = to both keys.
Current practice:
Lucid is said to implement the proposal. As far as I know all other
implementations do what CLtL currently says.
Cost to Implementors:
This requires a change in what is likely to be intricate and
implementation-dependent code. However, the total effort should
be small compared to the cost of writing that code originally.
Cost to Users:
This is an incompatible change. It's difficult to know if any users
are depending on the current behavior. It seems likely that most users
would expect the proposed behavior, and may be wondering why their
programs don't quite work when the numbers get large.
Cost of non-adoption:
Comparison functions in Common Lisp will be non-transitive.
Benefits:
Comparison functions in Common Lisp will be transitive.
Esthetics:
Having two rules of floating-point contagion may seem less esthetic,
but I'm certain that having the comparison functions behave in a more
mathematically correct fashion outweighs that esthetically.
Discussion:
Everyone who has expressed an opinion has thought this was the right
thing for years, but we never got around to writing it up as a cleanup
proposal.
∂14-Sep-88 1458 CL-Cleanup-mailer Re: issue TRUENAME-SYNTAX-ONLY
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Sep 88 14:58:13 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA15192; Wed, 14 Sep 88 15:56:52 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA19228; Wed, 14 Sep 88 15:56:45 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809142156.AA19228@defun.utah.edu>
Date: Wed, 14 Sep 88 15:56:44 MDT
Subject: Re: issue TRUENAME-SYNTAX-ONLY
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 14 Sep 88 15:54 EDT
> Date: Wed, 14 Sep 88 15:54 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Perhaps you can come up with a better description of what :SYNTAX-ONLY
> does? I appear to have struck out.
>
This issue seems to be getting bogged down in a morass; therefore, I
would like to withdraw my proposal. You've already indicated that you
would oppose the proposal on the grounds that it would take a
"near-infinite" amount of time to implement unless the behavior is
explicitly left vague, so there doesn't seem much point to my trying
to further clarify what the function must do.
> I don't see much point in
> adding this functionality to the language unless the spec is tight
> enough to ensure that it's going to solve the problem it was intended
> to.
>
> That could be a problem, especially if the problem it's intended to solve
> can't be precisely articulated in an implementation-independent way.
I think you're confusing "implementation-independent" with
"file-system-independent". As I have grumbled about before, all of
the pathname functions have this problem, not just the proposed
extension to TRUENAME. I think that the only alternative is to come
up with rules that all implementations must obey for specific file
systems: For files on BSD Unix hosts, the following values may be
supplied for such-and-such a pathname component. For files on VMS
hosts, this function returns X; for files on an MS-DOS host, the
function returns Y. Unless and until the standard goes into this kind
of detail, I don't think that *any* of the Common Lisp pathname
functions (except for coercion between namestrings and pathname
objects) can be used portably across implementations, even
implementations running on the same host. Granted, tightening up the
spec would cause implementors more work, but without it you might as
well throw out the pathname functions entirely, for all the good they
do users who are trying to write portable programs.
-Sandra
-------
∂14-Sep-88 2011 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 20:11:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 20:00:45 PDT
Date: 14 Sep 88 20:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
In-reply-to: Masinter.pa's message of 8 Jun 88 15:24 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <880914-200045-1692@Xerox>
The minutes from the June meeting say "The discussion of
DEFSTRUCT-DEFAULT-VALUE-EVALUATION led to no resolution of opinion so it was
decided not to bring the proposal to a motion."
I cannot recall what, if any, controversy was associated with this proposal.
JonL had some additional comments, but I didn't see that they would require any
changes to this issue per se (correct me if I am wrong.)
To refresh your memory:
!
Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION
References: CLtL p.308-10 & 86-003 p.4
Category: CLARIFICATION
Edit history: Revision 1 by Skona Brittain 05/13/88
Problem Description:
There is some confusion over whether default initialization
forms for defstruct slots get evaluated, when they are not needed
because a keyword argument was supplied to the constructor function.
As a consequence of this confusion, there is confusion over whether
there can be a type-mismatch error between the specified type of the slot
and the type of the default value.
On page 308, it says "The default-init is a form that is evaluated
each time a structure is to be constructed; the value is used as the
initial value of the slot. If no default-init is specified, then the
initial contents of the slot are undefined and implementation-dependent."
On the next page, however, it says that the default-init is evaluated if
the keyword argument is not supplied and the converse, although not stated,
is intended and informally implied.
Proposal (DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED):
Clarify that the converse is true. i.e that the default-init is not evaluated
if the keyword argument is supplied.
In the quote from page 308, delete the second sentence and replace
"a structure is to be constructed; the value is" by "its value is to be".
To section 19.3, add a clarification,
such as the following from Guy's issues file:
"The default value in a defstruct slot is not evaluated
unless it is needed in the creation of a particular structure
instance. If it is never needed, there can be no type-mismatch
error, even if the type of the slot is specified, and no warning
should be issued."
Test Case:
In the following sequence, only the last call is an error.
(defstruct person (name 007 :type string))
(make-person :name "James")
(make-person)
Rationale:
It is inefficient, and inconsistent with the rest of the language, for the
default initialization form to be evaluated when it is not needed.
Consequently, when it's not needed, such type-mismatch errors should not be
detectable in general.
Any existing confusion should be clarified by this proposal.
Current Practice:
KCL does not evaluate the default initialization form unless it is needed;
even when it is needed, the type checking is not done at all.
Cost to Implementors:
If there are any implementations that currently behave differently from
the proposed way, then they need some slight modification.
Cost to Users:
None.
Benefits:
Clarity and portability. In particular, clarifying that the unaesthetic
situation mentioned in the next section is allowed should be reassuring.
Aesthetics:
It appears slightly unaesthetic to have a default value that violates a
type specification.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
!
Additional notes:
Several members of the cleanup committee endorsed this proposal.
JonL added:
You can add to the "Current Practice:" section:
LUCID does not evaluate the default initialization form unless it is
needed; even when it is needed, the type checking is not done at all.
However, at structure definition time, if an initial value form is
constanp and doesn't satisfy the :type specification, a warning message
is printed.
Oddly enough, Lucid's interpreter ensures that SETF's of slots obey the
:type specifier, even though init-forms aren't checked. Furthermore, in
safety levels 2 or higher, the compiled code will do minimal "memory-
integrity" type checking for SETF's (which is what I suspect the various
special-purpose microcoded machines do); however except for low-level numeric
types, this is rarely equivalent to what a full type check would do.
I have long suggested that there should be at least one mode of operation
such that all :type information is checked when setting values into structure
slots (setf as well as initialization). Some have suggested that this mode
could be "when running interpretively, or when when compiled with the highest
degree of SAFETY and lower degrees of SPEED." However, since the wording of
CLtL p310 suggests that the :type slot options is merely a DECLARE, and since
some vendors effectively ignore any and all declarations [except for SPECIAL],
then this suggestion hasn't reached proposal stage yet.
∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-REDEFINITION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:07:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 21:31:45 PDT
Date: 14 Sep 88 21:31 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-REDEFINITION
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88
06:36:30 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <880914-213145-1852@Xerox>
Using the new terminology from the error/CLOS proposals, I would say that the
results of an old-use are undefined.
At the time the proposal was written, the new terminology wasn't around. I'm
looking for the copy of the new "error terminology" but I seem to have misfiled
it...
Xerox Common Lisp implements error-if-old-use: if a structure is redefined
*incompatibly*, old instances become invalid. An incompatible redefinition is
one that changes the number of slots or their type in an incompatible way (i.e.,
the total size or the layout of pointer vs. non-pointer fields changes.) A
warning message is printed if the underlying structure changes.
We might want to at least reference the redefintion protocol of CLOS.
Skona: there's been several comments; are you up for producing a new version?
Thanks,
Larry
∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:07:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 22:00:22 PDT
Date: 14 Sep 88 22:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DOTTED-MACRO-FORMS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 28 Jun 88 16:47 EDT
To: CL-Cleanup@SAIL.Stanford.EDU, goldman@VAXA.ISI.EDU
Message-ID: <880914-220022-1881@Xerox>
I apparently only responded privately to Walter last July, rather than to the
whole list.
I am in favor of DOTTED-MACRO-FORMS:ALLOW, with an addendum that a comment be
added to the standard where appropriate which says that such usage, while
allowed, is not good progamming practice and should be discouraged.
∂14-Sep-88 2207 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:07:39 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 88 21:52:51 PDT
Date: 14 Sep 88 21:53 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 13 Sep 88 12:32 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-215251-1875@Xerox>
The description of DESCRIBE says that it prints something on *standard-output*,
just like PRINT. While it doesn't explicitly prohibit DESCRIBE from being
interactive, it also doesn't prohibit PRINT from being interactive too.
So, I don't see any reason to claim that CLtL is any more vague than usual in
asserting that it is output only. If it were me, I'd treat this as a place where
Symbolics Genera diverged from CLtL.
I think that code that uses DESCRIBE to write out an implementation-dependent
description *is* fully portable, and that is part of the reason for having
DESCRIBE in the standard.
∂14-Sep-88 2207 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:07:32 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 21:41:19 PDT
Date: 14 Sep 88 21:41 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
TO: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880914-214119-1869@Xerox>
I've modified the proposal to say that it "should signal an error". This is shakey ground, but the sentiment from all that responded is that error-signalling is the desired behavior. I don't think the current "situations" language covers the distinction between macro expansion and evaluation, but I hope that we can invoke the distinction by reference and hope that it will appear in the standard...
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2 by Larry Masinter 14-Sep-88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL.
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same name.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name should
signal an error. (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.
Current Practice:
In KCL, if 2 slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
∂14-Sep-88 2213 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:13:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 22:11:31 PDT
Date: 14 Sep 88 22:10 PDT
From: masinter.pa@Xerox.COM
Subject: ELIMINATE-FORCED-CONSING
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-221131-1891@Xerox>
I'd like to get a sense of the committee on this issue... my guess is that the
best we can do is to report at the October meeting on the state of our
deliberation, and have the final issue ready by January.
My opinion on the issue:
I think the problem is a serious one, and that I don't want to discard the
issue. However, I'm not convinced that any of the proposed solutions actually
solve the stated problem, or are the minimum cost solutions to the problem.
In my mind, making CL more complicated is a very high cost.
What I remember from implementing stuff like this is that a :TARGET keyword just
doubles the size of the code for the functions, because the implementation when
:TARGET is supplied is completely different than the implementation when :TARGET
isn't supplied. This increases the size of the required image (because you can't
selectively compile stuff out) or else increases the complexity of the optimizer
(which has to decide whether the :TARGET is supplied), and increases the size of
error checking (what if :TARGET isn't big enough), increases the size of the
manual and the standard (describing all of these :TARGET arguments), and only
saves conses for a few applications.
∂14-Sep-88 2222 CL-Cleanup-mailer re: encourage no side-effect garbage
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:22:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 22:19:39 PDT
Date: 14 Sep 88 22:19 PDT
From: masinter.pa@Xerox.COM
Subject: re: encourage no side-effect garbage
In-reply-to: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU's message of Wed, 20 Jul 88
15:48:35 PDT
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880914-221939-1901@Xerox>
I'd like to withdraw this issue from discussion.
The cleanup committee is constituted to consider changes to the Language that
the standard describes. Whether the standard should have a (non-binding)
section on implementation notes is really up to the editor and the editorial
committee.
I think it should, but it doesn't belong as a "cleanup" to the language.
I think this is the sentiment that was expressed by others, but I wanted to give
final notice before moving it to the "withdrawn" category.
∂14-Sep-88 2331 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Sep 88 22:13:16 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 14 SEP 88 22:11:31 PDT
Date: 14 Sep 88 22:10 PDT
From: masinter.pa@Xerox.COM
Subject: ELIMINATE-FORCED-CONSING
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-221131-1891@Xerox>
I'd like to get a sense of the committee on this issue... my guess is that the
best we can do is to report at the October meeting on the state of our
deliberation, and have the final issue ready by January.
My opinion on the issue:
I think the problem is a serious one, and that I don't want to discard the
issue. However, I'm not convinced that any of the proposed solutions actually
solve the stated problem, or are the minimum cost solutions to the problem.
In my mind, making CL more complicated is a very high cost.
What I remember from implementing stuff like this is that a :TARGET keyword just
doubles the size of the code for the functions, because the implementation when
:TARGET is supplied is completely different than the implementation when :TARGET
isn't supplied. This increases the size of the required image (because you can't
selectively compile stuff out) or else increases the complexity of the optimizer
(which has to decide whether the :TARGET is supplied), and increases the size of
error checking (what if :TARGET isn't big enough), increases the size of the
manual and the standard (describing all of these :TARGET arguments), and only
saves conses for a few applications.
∂15-Sep-88 0018 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 00:18:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 14 SEP 88 23:01:25 PDT
Date: 14 Sep 88 23:01 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EXIT-EXTENT (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Wed, 7 Sep 88 19:32 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880914-230125-1950@Xerox>
I think this is a valuable generalization of the issue raised in
UNWIND-PROTECT-NON-LOCAL-EXIT.
My problem with this writeup is that it does not mention the numerous points for
the alternative proposal (which would extend the dynamic extent of an exit until
the exit was actually abandoned) from the discussion of
UNWIND-PROTECT-NON-LOCAL-EXIT. Since UNWIND-PROTECT-NON-LOCAL-EXIT was never
distributed, I think we at least need to acknowledge that there is an issue and
no small difference of opinion.
∂15-Sep-88 0018 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 00:18:36 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 14 SEP 88 22:35:47 PDT
Date: 14 Sep 88 22:35 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EQUAL-STRUCTURE (Version 2)
In-reply-to: Masinter.pa's message of 8 Jun 88 17:47 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <880914-223547-1922@Xerox>
Since this issue was distributed to X3J13 and debated there, in the mail, and on
the Common Lisp mailing list, we probably need to report on our disposition of
it.
My personal opinion is that we cannot fix EQUAL and EQUALP, and we are better
off leaving them alone. I would like to withdraw the issue; I don't see a need
for a "status quo" clarification.
∂15-Sep-88 0053 CL-Cleanup-mailer Committee meeting
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 00:53:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 00:44:31 PDT
Date: 15 Sep 88 00:44 PDT
From: masinter.pa@Xerox.COM
Subject: Committee meeting
To: cl-cleanup@Sail.stanford.edu
Message-ID: <880915-004431-2050@Xerox>
Given the time pressure, I would like to start early Monday and go until the
Editorial committee meeting starts. We have to come to some agreement on the
issues we can't resolve in the mail, else drop them.
Since January is supposed to be the final cleanup report for all current issues
(except those that arise due to CLOS, Editorial or other committee reports), I
hope that those of you who can participate will.
I imagine that those who are travelling should plan to do so on Sunday so that
we can start first thing Monday morning.
∂15-Sep-88 0117 CL-Cleanup-mailer Re: Issue FIXNUM-NONPORTABLE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 01:17:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 01:14:55 PDT
Date: 15 Sep 88 01:15 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NONPORTABLE (Version 1)
to: cl-cleanup@sail.stanford.edu
cc: Masinter.pa@Xerox.COM
Message-ID: <880915-011455-2083@Xerox>
I separated this issue from BOGUS-FIXNUM. Why don't we get this one out of the
way and then see what we have left?
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 15-Sep-88, Masinter
based on BOGUS-FIXNUM by Sandra Loosemore
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable, and allows programmers to use the
FIXNUM type specifier in a way similar to how the "int" type is used
in C.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing.
Cost to implementors:
Slight. All implementations I know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
Earlier versions of this proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations
might need to set MOST-POSITIVE-FIXNUM and MOST-NEGATIVE-FIXNUM
to arbitrary values, consistent with the requirement that (SIGNED-BYTE 16) is a
subtype of
FIXNUM.
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely
leave the range of FIXNUMs unconstrained and a SMALL-INTEGER type
with a fixed range (but no promises about efficiency) introduced.
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
∂15-Sep-88 1029 CL-Cleanup-mailer Re: Issue: EXIT-EXTENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Sep 88 10:28:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459750; Thu 15-Sep-88 13:17:59 EDT
Date: Thu, 15 Sep 88 13:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EXIT-EXTENT (Version 1)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880914-230125-1950@Xerox>
Message-ID: <19880915171725.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 14 Sep 88 23:01 PDT
From: masinter.pa@Xerox.COM
My problem with this writeup is that it does not mention the numerous points for
the alternative proposal
I think someone else will have to do that, as I found those points
unconvincing and in some cases incomprehensible. I don't think I
could do justice to them in a paraphrase.
∂15-Sep-88 1029 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Sep 88 10:28:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 459754; Thu 15-Sep-88 13:21:34 EDT
Date: Thu, 15 Sep 88 13:21 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880914-214119-1869@Xerox>
Message-ID: <19880915172113.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
This writeup doesn't say what precisely "the same" means, i.e. what
equality predicate are you using for slot names. The default assumption
when you don't say is EQL for most people. I think it should be
STRING=, because of the association of constructor keywords with slot
names. (What I really think is that it should be STRING-EQUAL, but
I'll probably have trouble convincing some people that case shouldn't
matter.)
∂15-Sep-88 1250 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 15 Sep 88 12:50:27 PDT
Received: by ti.com id AA17533; Thu, 15 Sep 88 14:48:05 CDT
Received: from Kelvin by tilde id AA08191; Thu, 15 Sep 88 14:39:45 CDT
Message-Id: <2799344496-16167493@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 15 Sep 88 14:41:36 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
In-Reply-To: Msg of Tue, 13 Sep 88 08:23:51 PDT from vanroggen%aitg.DEC@decwrl.dec.com
I think that much of the confusion about function type declarations is
because there are two aspects of the issue that have not been clearly
delimited:
1. Declarations describing the definition of a function.
2. Declarations about functions expected to be received by an argument
or variable.
The proposal FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE addresses
the first case, while the discussion in CLtL seems to have primarily the
second case in mind. I think that the point of the comment on pages 47-48
is that given
(DEFUN FFF (F)
(DECLARE (TYPE (FUNCTION (FLOAT STRING) LIST) F))
... (FUNCALL F (FOO ...) ...) ... )
then #'CONS is a valid argument to be passed to FFF because the declared
type of the argument is consistent with type (FUNCTION (T T) CONS).
Within FFF, the declaration permits us, for example, to assume that FOO
returns a FLOAT. I don't think this contradicts anything in the proposal
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS:RESTRICTIVE, but the proposal needs
to be extended to address this side of the issue also.
-- David Gray
∂15-Sep-88 1344 CL-Cleanup-mailer Re: Virginia and Hawaii X3J13 meetings
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 13:43:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 15 SEP 88 13:38:47 PDT
Date: 15 Sep 88 13:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Virginia and Hawaii X3J13 meetings
In-reply-to: your message of Thu, 15 Sep 88 13:27:36 PDT
To: Jan Zubkoff <jlz@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880915-133847-3035@Xerox>
I had in mind a cleanup meeting from 9:30 to 12:30.
OK, folks?
Return-Path: <jlz@lucid.com>
Received: from lucid.com ([192.26.25.1]) by Xerox.COM ; 15 SEP 88 13:30:00 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id
AA01280g; Thu, 15 Sep 88 12:29:49 PST
Received: by challenger id AA03845g; Thu, 15 Sep 88 13:27:36 PDT
Date: Thu, 15 Sep 88 13:27:36 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8809152027.AA03845@challenger>
To: Masinter.pa
In-Reply-To: Masinter.pa@Xerox.COM's message of 3 Sep 88 16:48 PDT
<880903-164817-8487@Xerox>
Subject: Virginia and Hawaii X3J13 meetings
What time would you like the cleanup committee to meet and for how long?
That's Monday 10/10
∂15-Sep-88 1351 CL-Cleanup-mailer Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Sep 88 13:51:25 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA13050; Thu, 15 Sep 88 14:50:04 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA19742; Thu, 15 Sep 88 14:50:02 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809152050.AA19742@defun.utah.edu>
Date: Thu, 15 Sep 88 14:50:01 MDT
Subject: Issue DEFSTRUCT-PRINT-FUNCTION-INHERITANCE, version 2
To: cl-cleanup@sail.stanford.edu
Issue: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE
References: CLtL p. 312-314
Category: CLARIFICATION
Edit History: V1, 5 Aug 1988, Sandra Loosemore
V2, 15 Sep 1988, Sandra Loosemore
Problem Description:
CLtL doesn't make clear whether defstructs that :INCLUDE another
structure type and do not specify a :PRINT-FUNCTION inherit the
:PRINT-FUNCTION of the parent structure type. While it is stated on
page 314 that #S syntax is used if a :PRINT-FUNCTION is not specified,
the language on page 313 indicates that all operations on the parent
type will also work on objects of the child type. Because of the
ambiguity, existing implementations have gone both ways, and users
cannot depend on either #S syntax or the parent type's :PRINT-FUNCTION
being used.
Proposal: DEFSTRUCT-PRINT-FUNCTION-INHERITANCE:YES
Clarify that defstruct types which :INCLUDE another type but do not
specify an explicit :PRINT-FUNCTION inherit the structure print
function from the :INCLUDE'd type. A print function that uses the
default #S syntax (overriding any print function for the parent type)
can be specified by providing the :PRINT-FUNCTION option without an
argument.
Rationale:
Users typically specify a print function for a structure type because
its slots will contain circular objects or large internal data
structures which are confusing when printed. Any structure type that
:INCLUDEs this type will also contain the same slots; it seems more
reasonable to inherit the parent's print function than to use the
default #S syntax.
Implementations may wish to use something like CLOS' DEFMETHOD to
implement structure printing, and such methods will naturally be
inherited from the :INCLUDE'd type.
Current Practice:
Lucid Common Lisp makes structures inherit print functions, as do both
Symbolics Genera and Cloe. VaxLisp uses #S syntax unless an explicit
:PRINT-FUNCTION is specified.
Cost to implementors:
The changes to non-conforming implementations should be fairly minor
and localized.
Cost to users:
It can't be any worse than the status quo.
Benefits:
An area of ambiguity in the language will be removed.
Discussion:
Pitman and VanRoggen support this proposal.
The original version of the proposal did not provide for a way to
force #S syntax to be used. This functionality was added to the
current version because there seemed to be general agreement that it
would be useful. Other alternatives would be to name the function
that does what the #S printer does, or to provide a function that
returns the #S information as a list (as suggested by Waters) so users
can write their own.
-------
∂15-Sep-88 1633 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 15 Sep 88 16:33:45 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA01587; Thu, 15 Sep 88 16:20:53 EDT
Received: by ti.com id AA17748; Thu, 15 Sep 88 15:18:59 CDT
Received: from Kelvin by tilde id AA08543; Thu, 15 Sep 88 15:03:48 CDT
Message-Id: <2799345941-16254274@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 15 Sep 88 15:05:41 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Dan L. Pierson" <pierson%mist@MULTIMAX.ARPA>
Cc: cl-cleanup%sail.stanford.edu@MULTIMAX.ARPA
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
In-Reply-To: Msg of Tue, 13 Sep 88 18:00:34 EDT from "Dan L. Pierson" <pierson%mist@MULTIMAX.ARPA>
> Unfortunately, the file loading feature of REQUIRE is specified such
> that it is inherently non-portable and environment dependent.
I think this could be specified in a portable way. Suppose we say that
the second argument of REQUIRE is a string or list of strings. Each
string must begin with a letter and contain only letters and digits. Then
if the indicated module is not present, REQUIRE calls the loader, using
each string as the name field of a pathname, defaulting the version to
:NEWEST and the rest of the pathname components to be the same as the file
in which the REQUIRE form was found, truncating the name if necessary to
make it legal. In other words, it loads additional files from the same
directory. I think this would work on all five of the file systems that I
use. Would it be useful enough to be worthwhile?
> Change the "Put in seven extremely random user interface commands"
> discussion to suggest that PROVIDE should be put at the end of the
> file rather than the beginning.
I agree with Zacharias that it's OK for PROVIDE to be at the beginning,
but an aborted load needs to un-do it.
-- David Gray
∂15-Sep-88 1852 CL-Cleanup-mailer Issue: FUNCTION-DEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Sep 88 18:52:43 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 15 SEP 88 18:37:37 PDT
Date: 15 Sep 88 18:37 PDT
From: masinter.pa@Xerox.COM
Subject:Issue: FUNCTION-DEFINITION (Version 1)
To: cl-cleanuP@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: no
Message-ID: <880915-183737-3576@Xerox>
Since people seem to have forgotten the original content of this
issue, I thought I would refresh your memory. Comments?
----- Begin Forwarded Messages -----
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 23 JUN 88 10:07:00 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Jun 88 10:05:16 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 423715; Thu 23-Jun-88 13:05:03 EDT
Date: Thu, 23 Jun 88 13:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-DEFINITION (Version 1)
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880623130442.4.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Issue: FUNCTION-DEFINITION
References: none
Category: ADDITION
Edit history: 23-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There are portable ways to turn symbols and lists into functions,
but there are no portable ways to get back the original symbols and
lists given the functions.
Proposal (FUNCTION-DEFINITION:OPTIONAL):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information, or to provide
primitives for flushing some or all of the information at any time.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is trivial. The following implementation is technically
legitimate, although many implementations would want to provide something
more useful:
(DEFUN FUNCTION-DEFINITION (FUNCTION)
(CHECK-TYPE FUNCTION FUNCTION)
(VALUES NIL NIL NIL))
Proposal (FUNCTION-DEFINITION:REQUIRED):
Introduce a new function called FUNCTION-DEFINITION which took as
its argument a function and returned three values:
#1: its ``definition'' as a symbol or list, or NIL if the
information was no longer available.
#2: NIL if the definition was enclosed in the null lexical
environment and something non-NIL if the definition was (or
might have been) enclosed in some non-null lexical environment.
[It is always safe for an implementation to return T for this
value.]
#3: the `name' of this function. the name is intended for debugging
only and may be any lisp object -- not necessarily one that would
be valid for use as a name in DEFUN or FUNCTION, for example.
By convention, NIL is used to mean that the function had no name.
Implementations would be free to not record this information in file
compilations. In-core calls to EVAL and COMPILE would be required to
retain the information, however.
Examples:
The following examples illustrate some possible return values, but
are not not intended to be exhaustive:
#1: (FUNCTION-DEFINITION #'(LAMBDA (X) X))
or (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (EVAL '(LAMBDA (X) X)))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#2: (FUNCTION-DEFINITION (FUNCALL #'(LAMBDA () #'(LAMBDA (X) X))))
might return NIL, NIL, NIL
or (LAMBDA (X) NIL), T, NIL
but -not- (LAMBDA (X) X), NIL, NIL
in compiled code.
(FUNCTION-DEFINITION (FUNCALL (EVAL '(LAMBDA () #'(LAMBDA (X) X)))))
would not be permitted to return NIL, NIL, NIL since the compilation
occurred in the same environment.
#3: (DEFUN FOO (X) X)
(SETF (SYMBOL-FUNCTION #'BAR) #'FOO)
(DEFUN FOO (Y) Y)
(FUNCTION-DEFINITION #'BAR)
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, FOO
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
#4: (DEFUN FOO ()
(FLET ((BAR (X) X))
#'BAR))
(FUNCTION-DEFINITION (FOO))
might return NIL, NIL, NIL
or (LAMBDA (X) X), T, NIL
or (LAMBDA (X) X), T, (:INTERNAL FOO 0 BAR)
or (LAMBDA (X) X), T, "BAR in FOO"
in compiled code.
If the DEFUN had been done interactively, the call to
FUNCTION-DEFINITION would not be permitted to return NIL, NIL, NIL
since the compilation occurred in the same environment.
Rationale:
This functionality would be useful to the pretty printer, debugger,
inspector, and other tools.
Additionally, this would be useful to programs which need to pass
around both a function and a representation of a function because a
single object could be passed which was efficient to call without
compromising the ability to reliably retrieve its representation.
Cost to Implementors:
Because NIL can be returned as a first value, the amount of work forced
by this proposal is small, but not trivial. A simple implementation
might allocate a slot in each function that could hold the definition,
or might allocate a hash table to hold the information.
Current Practice:
Many implementations record this information, but not all that do
publish an interface to extracting the information.
The language T has this operation and calls it DISCLOSE. It is the
conceptual inverse of the ENCLOSE which occurs in some Scheme dialects,
and is implemented as what CLOS would call a "generic function".
Cost to Users:
None. The change is upward compatible.
Cost of Non-Adoption:
Certain kinds of portable debugging tools would be harder to write.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
The phrase ``program is data; data is program'' comes up a lot in discussions
about Lisp. This makes the case for ``program is data'' more interesting.
Discussion:
Pitman would prefer FUNCTION-DEFINITION:REQUIRED if people would agree to it
because it is considerably more useful in practice, but would like to see at
least FUNCTION-DEFINITION:OPTIONAL.
----- End Forwarded Messages -----
∂16-Sep-88 0005 CL-Cleanup-mailer Re: Issue: HASH-TABLE-ACCESS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 00:05:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 88 00:04:25 PDT
Date: 16 Sep 88 00:04 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-ACCESS (version 1)
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88
12:30:52 PDT
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880916-000425-3811@Xerox>
Is it reasonable for implementations to extend the set of SETF-able forms? It
would seem to lead to more subtle incompatibilities, because there would be no
simple lexical analysis that would determine the use of an extension vs the
standard. Further, I don't think that HASH-TABLE-SIZE HASH-TABLE-TEST, are
reasonably SETF-able. If you change the :TEST, would would you do about entries
that now collide?
It would make more sense to make HASH-TABLE-REHASH-SIZE
HASH-TABLE-REHASH-THRESHOLD
both SETFable if it is reasonable to expect to do so.
I wonder before we add more "instance variables" for built in data structures if
we wouldn't be doing better if we made access to these via CLOS? I won't push on
that too hard....
∂16-Sep-88 0145 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 01:45:06 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 88 01:42:56 PDT
Date: 16 Sep 88 01:43 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 12 Sep 88 20:25 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880916-014256-3857@Xerox>
I have a note that there was some discussion on this issue, but I don't see it.
What I think is that this issue doesn't give us much clarification unless we can
pin down what a component is (e.g., "it is an error to modify a component of a
key" doesn't disallow changing the symbol-function of a symbol key, although it
might be considered a "component" of the KEY.
Given that EQUAL is transitive, the operation is that
if before the operation, there is a value B suchthat (EQUAL A B), but after the
operation on A, (EQUAL A B) is false, then you've changed something that GETHASH
cares about wrt EQUAL hash keys.
Should implementations really be free to signal an error or behave otherwise in
an undefined manner when you say (setf (car x) y) if x happens to be a key in a
EQUAL hash table?
I think we can and should be more precise than "is an error" when we can, and
this is such an opportunity. The value of GETHASH on B or A is unspecified after
A is modified if the value of A is a key in the hash table.
...
∂16-Sep-88 0156 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 01:56:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 88 01:55:07 PDT
Date: 16 Sep 88 01:55 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
In-reply-to: Jon L White <edsel!jonl@labrea.stanford.edu>'s message of Wed, 25
May 88 13:12:47 PDT
To: cl-cleanup@sail.stanford.edu, cliter@sail.stanford.edu
Message-ID: <880916-015507-3866@Xerox>
There was an interesting interchange on this proposal back in May, but no good
resolution. Would someone care to review the messages and extract a revised
proposal? I think we can't ignore locking because there is a way to implement
iterators without locking. Moon says "You need to be able to wrap something
around the whole iteration,
not merely have a function that performs the next step in the iteration...."
Or is this issue moot? E.g., if implementations are required to provide LOOP and
OSS (even as a loadable libraries), is there any purpose served in also making
the lowlevel mechanism visible?
∂16-Sep-88 0202 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 02:01:59 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 88 02:00:14 PDT
Date: 16 Sep 88 02:00 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 31 May 88 11:38 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Dave.Touretzky@B.GP.CS.CMU.EDU, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880916-020014-3872@Xerox>
When we discussed this issue in May and early June, the open issue was whether
we were going to go for complete+hairy or incomplete+simple, e.g., whether it
was #H((A B) (C D)) or some other variation with all the options. (There were
several variations proposed.)
I have no notes of any additional comments made by the X3J13 body; do any of
you?
∂16-Sep-88 0241 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 02:41:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 88 02:40:06 PDT
Date: 16 Sep 88 02:40 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: LAMBDA-FORM (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Wed, 22 Jun 88 18:07 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880916-024006-3889@Xerox>
I think this issue needs only minor patches. I think that the improvement of
aesthetics has a counterbalance, in that it makes the language slightly larger;
however, it is a minor increment.(The phrase "gilding the lilly" comes to mind,
but at this hour I'm no longer sure what it means.)
I guess we should come out with NEW-MACRO and mention in the discussion that we
considered NEW-SPECIAL-FORM.
Other opinions?
∂16-Sep-88 0755 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Sep 88 07:55:09 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 460367; Fri 16-Sep-88 10:53:31 EDT
Date: Fri, 16 Sep 88 10:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LAMBDA-FORM (Version 2)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880916-024006-3889@Xerox>
Message-ID: <880916105334.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 16 Sep 88 02:40 PDT
From: masinter.pa@Xerox.COM
I think this issue needs only minor patches...
I guess we should come out with NEW-MACRO and mention in the discussion that we
considered NEW-SPECIAL-FORM.
Other opinions?
I concur.
Here's a proposed rewrite. I took care of Walter's concern about the
"technicality" alluded to at one point in the current practice by moving
it to the discussion and expanding it.
-----
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
Improved aesthetics.
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe strongly that (LAMBDA ...) looks a lot better
than #'(LAMBDA ...). Certainly it takes up fewer characters, and
(LAMBDA ...) is a notable offender in code needing to be split onto
multiple lines, so every little bit helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions,etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item addresses this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form, but most people seemed to prefer the
simpler alternative of just making it a macro for now.
∂16-Sep-88 0837 CL-Cleanup-mailer Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Sep 88 08:37:30 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 460400; Fri 16-Sep-88 11:36:01 EDT
Date: Fri, 16 Sep 88 11:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COERCE-TIME (Version 2)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880915-183212-3570@Xerox>
References: <880620160959.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<880623103735.0.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<880622-225811-3055@Xerox>
Message-ID: <880916113555.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 15 Sep 88 18:32 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-COERCE-TIME (Version 1)
I don't have any further correspondence on file after this.
Did you send a revision?
Nope, but here's one now. I changed the wording significantly enough
that each warrants a careful re-reading. Anyway, hope this satisfies
your criticisms about vagueness.
-----
Issue: FUNCTION-COERCE-TIME
References: SET-MACRO-CHARACTER (p362),
SET-DISPATCH-MACRO-CHARACTER (p364),
MAP (p249), MAPL (p129), ...
Functions using :TEST, :KEY, etc. (REDUCE, MEMBER, DELETE, ...)
Functions using a positional predicate (SORT, DELETE-IF, ...)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
(changes to presentation of all proposals per Masinter's comments)
Status: For Internal Discussion
Problem Description:
Many functions which accept arguments which are to be treated functionally
but which are not of type FUNCTION. This functionality can be very useful,
but the time at which the coercion is accomplished must be made clear.
Proposal (FUNCTION-COERCE-TIME:LAZY):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is delayed until the function is about to be called and is done anew
every time the function is to be called. That is, passing a non-function
functional argument, F, is equivalent to passing
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
Rationale:
One of the main reasons that it may be useful to pass a non-function
instead of a function is to accomplish indirection which allows later
redefinitions to take proper effect. Early binding would tend to
thwart the usefulness of such indirection and force people into
notationally more clumsy devices.
Proposal (FUNCTION-COERCE-TIME:AMBITIOUS):
Specify that when a non-function (eg, a symbol) is used as a functional
argument to an operator, the coercion of that non-function to a function
is done immediately. That is, all such functions treat a non-function
functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead.
Rationale:
This is easier to implement since the coercion is done up front and
no further worry about uncoerced functions is needed internally.
Also, inlining of mapped functions (without using temporary storage
to hold a cached value of the function being mapped) can be done
without needing to know whether the function being inlined will
affect the place which holds the functional argument being passed.
Proposal (FUNCTION-COERCE-TIME:HYBRID):
Specify that when a non-function (eg, a symbol) is used as a
functional argument to an operator, the coercion of that non-function
to a function must be done immediately if the functional argument is
to be used only internally to the function (eg, SORT or MAPCAR).
Otherwise, if the functional argument's use persists beyond the end
of the call to the operator (eg, SET-MACRO-CHARACTER), any coercion is
delayed until the function is about to be called and is done anew every
time the function is to be called.
That is, functions like SORT and MAPCAR are permitted to treat a
non-function functional argument, F, as if
(COERCE F 'FUNCTION)
had been passed instead. However, functions like SET-MACRO-CHARACTER
would treat a non-function functional argument, F, as if
#'(LAMBDA (&REST ARGUMENTS)
(APPLY F ARGUMENTS))
were passed instead.
Rationale:
Debugging is enhanced for operations such as SET-MACRO-CHARACTER
without needlessly hampering useful optimizations to things like
SORT or MAPCAR, which very rarely require this facility.
Test Cases:
(DEFVAR *SOME-FUNCTIONS*
(LIST #'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 1)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 2)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 3)
#'(LAMBDA (X) (SETF (SYMBOL-FUNCTION 'FOO) X) 4)))
; Control situation A
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'(LAMBDA (&REST X) (APPLY #'FOO X))
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4)
; Control situation B
(LET ((FOO (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))))
(LIST (MAPCAR FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 1 1) 4)
; Interesting Situation 1
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR #'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-1
or ((1 1 1 1) 4) ;Ambitious-1
; Interesting Situation 2
(PROGN (SETF (SYMBOL-FUNCTION 'FOO) (CAR *SOME-FUNCTIONS*))
(LIST (MAPCAR 'FOO
*SOME-FUNCTIONS*)
(FOO T)))
=> ((1 1 2 3) 4) ;Lazy-2
or ((1 1 1 1) 4) ;Ambitious-2
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(EXPT (READ STREAM) (OR N 1)))
(SET-DISPATCH-MACRO-CHARACTER #\# #\$ 'SHARP-DOLLAR)
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3 81)
(DEFUN SHARP-DOLLAR (STREAM CHAR N)
(DECLARE (IGNORE CHAR))
(+ (READ STREAM) (* (OR N 0) 0.01)))
(VALUES (READ-FROM-STRING "(#$3 #4$3)"))
=> (3.0 3.04) ;Lazy-3
(3 81) ;Ambitious-3
Proposal LAZY requires LAZY-1, LAZY-2, LAZY-3.
Proposal AMBITIOUS requires AMBITIOUS-1, AMBITIOUS-2, AMBITIOUS-3.
Proposal HYBRID requires AMBITIOUS-1, AMBITIOUS-2, LAZY-3.
Current Practice:
Implementations are permitted to differ in when they do the coercion since
the coercion time is not clearly spelled out.
(In the test case, LAZY-1 can occur only if MAPCAR is inlined, and then
only if the original value of the function definition is not cached.)
[Some info below is based on empirical testing -- I didn't look at the
source or try to see how speed/safety affect things. -kmp]
Symbolics Genera implements AMBITIOUS-1 interpreted and LAZY-1 compiled.
Symbolics Cloe (a compiled-only lisp) implements LAZY-1 both `interpreted'
and compiled.
Both Symbolics Genera and Symbolics Cloe implement LAZY-2.
Symbolics Genera implements LAZY-3.
Symbolics Cloe implements AMBITIOUS-3.
Cost to Implementors:
[Costs may vary widely depending on current practice.
I'll leave this one open for now pending feedback from others. -kmp]
Cost to Users:
This change is upward compatible.
Cost of Non-Adoption:
A very important aspect of the language would be left unspecified.
Portability would suffer.
Benefits:
HYBRID has the benefit of making things like readmacros easier to debug.
LAZY offers the additional benefit of being able to repair certain
functional arguments to SORT or MAPCAR (eg, as a symbol) in the debugger,
and then to proceed the error (in implementations offering that restart
option) in a way that makes the ongoing call to SORT or MAPCAR notice
the repairwork right away.
Aesthetics:
Since this is a visible aspect of the language, anything which clarified
the behavior that a programmer might expect would seem to improve the
aesthetics somewhat.
Discussion:
This issue was raised by Nick Gall and written up by Pitman.
Pitman supports FUNCTION-COERCE-TIME:HYBRID.
∂16-Sep-88 1603 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Sep 88 16:03:22 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 460705; 16 Sep 88 19:01:32 EDT
Date: Fri, 16 Sep 88 19:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LAMBDA-FORM (Version 2)
To: masinter.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880916-153700-1591@Xerox>
Message-ID: <880916190136.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 16 Sep 88 15:37 PDT
From: masinter.pa@Xerox.COM
... I think we do well when we at least acknowledge the pros
and cons in issues,
Sure.
and this one isn't as clearcut as the writeup makes it out to be.
I think simply mentioning your concern under aesthetics is enough.
People can then read it and decide if it bugs them.
There are several ways of rationalizing the dual existence of
(lambda ...) and #'(lambda ...).
One says that you'd have flushed #'(lambda ...) if only you could have
but you couldn't for compatibility reasons. I personally think the
situation is more complicated than this, but I have no doubt that some
people hold this position. In any case, there's no argument with the
fact that if people convert from #'(lambda ...) to (lambda ...), it'll
be easier to tell whether there are places that such a changeover
cannot be done and why. [Some of the reasons may be philosophical, not
technical.]
Another argument says that (LAMBDA ...) creates a closure, while
(FUNCTION ...) accesses a function by name -- and that (LAMBDA ...)
is the name of the closure which is created by (LAMBDA ...). So while
they do functionally the same thing, they could be argued to be
intentionally different (like NOT and NULL -- surely there must have
been dispute over that, but it definitely turned out to be a good
distinction to make). I'm a fan of this argument.
Yet another argument says that since #'(LAMBDA ...) is used so much
and is so cumbersome to type, ``two fewer spaces of indentation'' is
a stronger argument than ``one more function.'' If everyone had a
LAMBDA (Greek-L) key on their keyboard, you can bet I'd advocate
allowing (λ ...) as a synonym as well, just on syntactic grounds.
[Well, it looked like a LAMBDA on -my- screen! But I suppose it
looks like BS to the rest of you, huh? :-]
∂16-Sep-88 1629 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from mist.math.uoregon.edu by SAIL.Stanford.EDU with TCP; 16 Sep 88 16:29:14 PDT
Received: from fog.cs.uoregon.edu by mist.math.uoregon.edu; Fri, 16 Sep 88 16:24:53 PDT
Received: by fog.cs.uoregon.edu; Fri, 16 Sep 88 16:24:45 PDT
Date: Fri, 16 Sep 88 16:24:45 PDT
From: William Clinger <will@fog.cs.uoregon.edu>
Message-Id: <8809162324.AA19754@fog.cs.uoregon.edu>
To: Gray@DSG.csc.ti.com, vanroggen%aitg.DEC@decwrl.dec.com
Subject: Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Perhaps what I am about to say is obvious or has already been pointed out
(I haven't been paying much attention to this discussion), but David Gray's
note is related to the fact that the function type constructor is anti-
monotonic in its first argument, unlike most other other type constructors
which are monotonic in all arguments. That is,
If X is a subtype of Y
then Z --> X is a subtype of Z --> Y
but Y --> Z is a subtype of X --> Z.
It would be good if Common Lisp's notion of "type" and "subtype" could
be made consistent with this fact.
Peace, Will
∂16-Sep-88 1752 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 17:51:51 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 16 SEP 88 15:37:00 PDT
Date: 16 Sep 88 15:37 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: LAMBDA-FORM (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Fri, 16 Sep 88 10:53 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880916-153700-1591@Xerox>
In re-reading, I realize that there is a small counter to the Aesthetic argument
that says that since it makes the language slightly bigger, with two ways of
doing the same thing: you can now say (lambda (x) ...) or #'(lambda (x) ...),
and thus makes the language more confusing, harder to explain, read, etc.
I think we do well when we at least acknowledge the pros and cons in issues, and
this one isn't as clearcut as the writeup makes it out to be.
∂16-Sep-88 1752 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Sep 88 17:51:57 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 16 SEP 88 15:47:41 PDT
Date: 16 Sep 88 15:47 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Wed, 14 Sep 88 13:08 EDT
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880916-154741-1618@Xerox>
I concur with the sentiment that the portability of default :USE is more
important than the slight ease of use, especially given the simple workaround
used by CLOE.
The proposal as worded says "Specify that the LISP package must contain not only
all the symbols
mentioned as part of the LISP package in standard, but only those symbols."
I don't think you intend to disallow *internal* symbols in the LISP package,
just *external* symbols, right?
Also, it should say that the USER package should have *no* symbols, right? I.e.,
USER uses LISP, is empty, and LISP has no symbols. This gives you a way of
writing portable code that you know is portable..... (well, insofar as other
symbols are defined.)
We should be careful about the word "must". Normally, "must" is associated with
the action of user programs: a user program "must" supply an integer to this
function otherwise it "is an error". However, this proposal is a constraint on
Common Lisp implementors and not on Common Lisp programs. Perhaps we can rely on
the editor to make the transition to the correct case, but is there a simple way
of expressing it in terms of valid programs? Perhaps that is an issue for the
editorial committee.
∂16-Sep-88 2307 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 16 Sep 88 23:07:21 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 17 Sep 88 02:04:05 EDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Your message of 16 Sep 88 15:47:00 -0700.
<880916-154741-1618@Xerox>
Date: Sat, 17 Sep 88 02:02:12 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Also, it should say that the USER package should have *no* symbols, right? I.e.,
USER uses LISP, is empty, and LISP has no symbols. This gives you a way of
writing portable code that you know is portable..... (well, insofar as other
symbols are defined.)
If you're saying what I think you're saying, I am opposed to this. Back
when we all agreed that LISP should export only the symbols mentioned in
CLtL (or the standard that replaces it), I thought that we also agreed that
USER was the place where an implementation was allowed to provide its
default environment. This means CLtL symbols plus whatever other stuff an
implementation wants to define as extensions: debugging functions, graphics
stuff, or whatever.
If someone wants a completely empty package that uses only Lisp, they
should create one. That's easy and portable.
-- Scott
∂17-Sep-88 0907 CL-Cleanup-mailer Re: Issue: LAMBDA-FORM (Version 2)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Sep 88 09:04:26 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03846; 17 Sep 88 16:20 BST
Date: Sat, 17 Sep 88 16:54:47 BST
Message-Id: <2325.8809171554@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: LAMBDA-FORM (Version 2)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, masinter.pa@xerox.com
In-Reply-To: Kent M Pitman's message of Fri, 16 Sep 88 19:01 EDT
Cc: CL-Cleanup@sail.stanford.edu
BTW, I would prefer that LAMBDA be a special form rather than a macro
so that (LAMBDA ...) rather than (FUNCTION (LAMBDA ...)) could be
considered the more fundamental form.
> There are several ways of rationalizing the dual existence of
> (lambda ...) and #'(lambda ...).
>
> One says that you'd have flushed #'(lambda ...) if only you could have
> but you couldn't for compatibility reasons. I personally think the
> situation is more complicated than this,
I do too. For one thing, I may be convenient to speak of a single
case, FUNCTION, rather than two, LAMBDA-expressions and (FUNCTION
<symbol>).
> Another argument says that (LAMBDA ...) creates a closure, while
> (FUNCTION ...) accesses a function by name -- and that (LAMBDA ...)
> is the name of the closure which is created by (LAMBDA ...).
> [...] I'm a fan of this argument.
I guess I am too, given the overlong discussion of whether FUNCTION
should simply access a value or create one on the general CL list.
∂17-Sep-88 1320 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Sep 88 13:19:59 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 88 13:18:10 PDT
Date: 17 Sep 88 13:18 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Sat, 17 Sep 88 15:03 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Scott.Fahlman@B.GP.CS.CMU.EDU, Masinter.PA@Xerox.COM,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880917-131810-2375@Xerox>
Sometimes when you write a treaty, you just don't talk about the things that you
think you might not agree about. However, a language specification has to be a
bit more precise, especially in those areas where there really is a question.
I think that either the standard should be completely silent about USER -- e.g.,
say "the initial package should be something other than LISP and the
implementation should document what it is...", or else be explicit about it.
What's the point of requiring this otherwise useless package? Again, this is a
requirement for implementation rather than programs.
If we want to point out to implementors in the notes the risk of internal uses
of external symbols, I think that's OK as an 'implementation note', but I don't
think its a good reason for forbidding the use of internal symbols in LISP. And
that DO-SYMBOLS might differ from implementation to implementation is not
significantly different than the fact that DO-ALL-SYMBOLS might do so also.
This reminds me of my desire to have a general non-exclusive registry of
package, feature and module names. I'm thinking about how to best set it up..,
but that's a separate topic.
∂17-Sep-88 1414 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from SEF1.SLISP.CS.CMU.EDU ([128.2.218.13]) by SAIL.Stanford.EDU with TCP; 17 Sep 88 14:13:55 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 17 Sep 88 17:10:49 EDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Your message of 17 Sep 88 13:18:00 -0700.
<880917-131810-2375@Xerox>
Date: Sat, 17 Sep 88 17:10:24 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I think that either the standard should be completely silent about USER -- e.g.,
say "the initial package should be something other than LISP and the
implementation should document what it is...", or else be explicit about it.
What's the point of requiring this otherwise useless package? Again, this is a
requirement for implementation rather than programs.
I agree that users should be told that the initial package may be something
other than Lisp, and that it may have implementation=specific stuff in it
which is presumably documented. I see no harm in saying that this initaial
package is named USER, but that its contents will differ from one
implementation to another. Then people who see this package name will at
least know what is going on. On the other hand, there's no compelling
reason why a standard name is needed for this non-standard thing. As long
as we're allowed to keep calling it USER, I don't really care whether
everyone is forced to call it that. Some implementaitons might want to
come up with LISP as the default, I suppose.
I think that there will definitely be at least a minor fight if someone
proposes to eliminate all the internal symbols of LISP. That's an
incompatible change, for us at least, and the only reason for it is to
prevent errors when a user is doing something wrong in the first place.
You don't live in Lisp unless you're the implementor; others should just
USE it. As with any package, if you get into its insides, you are
responsible for knowing about what's already in there.
-- Scott
∂17-Sep-88 1504 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Sep 88 15:04:48 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 17 SEP 88 15:02:50 PDT
Date: 17 Sep 88 15:02 PDT
From: masinter.pa@Xerox.COM
to: cl-cleanup@Sail.stanford.edu
Subject: LISP-SYMBOL-REDEFINITION
cc: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
Message-ID: <880917-150250-2427@Xerox>
This issue was discussed on this mail list over a year ago, and has come up from
time to time on the general Common Lisp list. For a while, there was a volunteer
for creating a writup, but the mail to the volunteer was returned. So...
finally....
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88
Problem description:
CLtL allows the redefinition of functions exported from other packages.
Unexperienced programmers may redefine a system function unintentional which
may result into an inconsistent state of the system and cause to abort. This
has happened, for example, with a beginner follows an introductory
book where an exercise asks to define a function make-list. After the
redefinition of make-list the system crashs without returning a message that the
function has been redefined.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function or variable any of the functions,
macros, special forms, or constants defined in the LISP package are unspecified;
similarly, the result of locally binding (with LAMBDA, LET, LET* etc) any
constant, or lexically defining (with FLET or LABELS) any function in the LISP
package is unspecified.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means that
is, implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(defun car (x) (cdr x))
might signal an error.
Rationale:
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
∂17-Sep-88 1514 CL-Cleanup-mailer Re: list type cleanup
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Sep 88 15:14:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 88 15:11:19 PDT
Date: 17 Sep 88 15:11 PDT
From: masinter.pa@Xerox.COM
Subject: Re: list type cleanup
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
Aug 88 15:25:52 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880917-151119-2438@Xerox>
While this seems to be useful functionality, there is a difference between the
LIST type specifiers and the ARRAY type specifiers in that the type of a LIST
object is mutable, e.g.,
(typep x '(list number))
(setf (car y) t)
(typep x '(list number))
is false, while normally, for built in type designators that do not involve
SATISFIES, no side effect operation (other than changing the direct binding of
X) can affect the value of TYPEP for that binding.
Given the mutability of the type designators, I question your assertion "There
is a need in common lisp for more accurate type specifiers
for lists."
I can believe there is a need for a general database interface, and also for a
portable window system.
However, I'm not sure I can admit to knowing what the need here is without some
examples of how it might be used, and where the proposed use is more reasonable,
efficient than the alternative (would you advocate programers say
(typep x '(list number symbol)) instead of
(and (listp x) (numberp (car x)) (symbolp (cadr x)))?
Should it check (null (cddr x))?
Should it be written
(and (consp x) (numberp (car x)) (consp (cdr x)) (symbolp (cadr x)) (null (cddr
x))) ?
I guess I would call it ADDITION instead of COMPATIBLE CHANGE. The distinction
between a CHANGE and an ADDITION in my mind is whether it makes the language
(its description and its implementation) smaller or larger.
∂17-Sep-88 1517 CL-Cleanup-mailer [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue:
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Sep 88 15:16:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 88 15:15:15 PDT
Date: 17 Sep 88 15:15 PDT
From: masinter.pa@Xerox.COM
Subject: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue:
LOAD-TIME-EVAL (Version 5)]
To: cl-cleanup@sail.stanford.edu
Message-ID: <880917-151515-2442@Xerox>
I think this is a moderately useful issue to be resolves if the compiler
committee hasn't done so. I'm not on cl-compiler so I don't know what, if any,
progress has been made on the numerous issues that were deferred to them. Was
this one of them?
----- Begin Forwarded Messages -----
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 08 JUN 88 14:00:52 PDT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by
SAIL.Stanford.EDU with TCP; 8 Jun 88 13:56:15 PDT
Received: from PEWEE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via
INTERNET with SMTP id 416590; 8 Jun 88 16:55:29 EDT
Date: Wed, 8 Jun 88 16:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 5)
To: CL-Cleanup@SAIL.STANFORD.EDU
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Message-ID: <880608165454.0.KMP@PEWEE.SCRC.Symbolics.COM>
Well, this really needs a lot more polish, but I don't have more time to
spend on it today and I wanted to get it out for people to look at
before we meet next week. This is definitely a rough cut and I'm sure it
won't want to go to committee in this form, but at least now all the
proposals are under a single cover and we don't have to play leap-frog
with Moon removing my proposal or my removing his (unless one of us
gives in).
-----
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
Status: For internal discussion
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Also, CLtL is vague about whether the result of this early evaluation
is re-evaluated at runtime. The meaning of #,exp in an for-evaluation
position is unclear. Although CLtL doesn't come out and say so explicitly,
portable code must currently use only '#,exp to get consistent behavior
across implementations.
CLtL is also vague on whether the result of a #, expression may be
treated as a read-only constant by the loader (and hence shared with
other programs). Users probably want some both read-only and modifiable
load-time constants, so this may not be simply an issue of deciding on
a single "right answer".
Proposal (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN):
Add a function MAKE-LOAD-TIME-CONSTANT, as described here:
MAKE-LOAD-TIME-CONSTANT form env &optional read-only-p [Function]
FORM is a Lisp form. ENV is an environment of the sort received
by the &ENVIRONMENT argument to a macro.
When MAKE-LOAD-TIME-CONSTANT is called from the interpreter or the
COMPILE function, it simply evaluates FORM in the null lexical
environment and returns its value. When MAKE-LOAD-TIME-CONSTANT is
called during a file compilation, the result is a special object
that is recognized at load time, when it occurs inside a constant.
At load time, FORM is evaluated and its value is substituted for
the object.
MAKE-LOAD-TIME-CONSTANT uses its ENV argument and/or dynamic state
to determine whether it is being called during a file compilation.
Until Common Lisp is modified to specify the semantics of file
compilation more precisely, this is necessarily implementation
dependent.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL, the result must be considered ordinary,
modifiable data. If T, the result is a read-only quantity which may, as
appropriate, be copied into read-only space and/or shared with other
programs.
Specify that '(... #,exp ...) is equivalent to
#.`(... ,(MAKE-LOAD-TIME-CONSTANT exp NIL T) ...).
Rationale:
This approach is the most compatible with existing practice.
Cost to Implementors:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-CONSTANT may already exist, in others, more substantial
changes may be required.
Cost to Users:
This change is upward compatible with user code.
Benefits:
It would be possible for macros to expand into load time constants.
Examples:
Case QUOTED-MAGIC-TOKEN-1:
(defmacro print-software-version (&environment env)
`(quote ,(make-load-time-constant
'(format T "~A~%" (software-version))
env)))
When interpreted or processed during invocation of COMPILE, this
macro prints the value of (software-version) at macro expansion
time and expands into (quote nil). When macroexpanded during a
file compilation, printing is deferred until the compiled file is
loaded, and the constant is still (quote nil).
Case QUOTED-MAGIC-TOKEN-2:
(defmacro table-of-tables (&rest predicates &environment env)
`(quote ,(mapcar #'(lambda (predicate)
`(,predicate
,(make-load-time-constant
`(make-hash-table :test ',predicate)
env)))
predicates)))
(table-of-tables eql equal) expands into
(quote ((eql #<table :test eql>) (equal #<table :test equal>)))
except that when macroexpanded during a file compilation,
the tables are not created until load time. This example
shows that the <object> returned by make-load-time-constant is
recognized even when it is interior to a quoted constant.
Proposal (LOAD-TIME-EVAL:NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-CONSTANT, which has the following
contract:
LOAD-TIME-CONSTANT form &optional read-only-p [Special Form]
All processing of the FORM is deferred until the expression is
in the "runtime" environment. Once that environment is available,
FORM is evaluated in the null lexical environment and the result
is both returned and saved for immediate access by the program
on subsequent evaluations.
In the interpreter, the FORM may be evaluated during pre-processing
(if any) or dynamically when the LOAD-TIME-CONSTANT is first seen
(in a non-pre-processing implementation). If the same LOAD-TIME-CONSTANT
expression is later seen again by the interpreter, the previously
obtained result is immediately retrieved and returned as the result
of evaluating the object; no re-evaluation occurs.
If the LOAD-TIME-CONSTANT expression is seen by the file compiler
(eg, COMPILE-FILE), the compiler arranges for all semantic processing
of FORM (including macro expansion) to occur at load time in a null
lexical environment (independent of whether any value has been cached
for interpreter use). At runtime, the result of that evaluation will
be treated as an immediate quantity; no re-evaluation occurs.
If a LOAD-TIME-CONSTANT expression is seen by the runtime compiler
(eg, COMPILE), the compiler checks for a cached value which may have
been produced by the interpreter. If one is found, it is used. If no
such value is found, the runtime compiler will evaluate the FORM in
a null lexical environment and use that value. The value used will be
treated as an immediate quantity in the code which is produced; no
re-evaluation occurs.
Note that since some implementations are compiled-only (that is, they
implement their interpreter using a compiler pre-pass) and some are
interpreted-only (that is, they implement their compiler as a null
operation and use only an interpreter), the question of whether the
interpreter or the compiler will end up doing the processing is left
somewhat vague. The programmer may assume only that the given FORM
will be evaluated only once for each time it is loaded into a runtime
environment.
Note, however, that in the case of quoted code (processed by explicit
use of EVAL), each call to EVAL is treated like a load. Caching may not
be implemented by having LOAD-TIME-CONSTANT displace its source level
call. So while
(DEFVAR *FOO* 1)
(DEFUN FOO () (LOAD-TIME-CONSTANT (INCF *FOO*)))
will increment *FOO* only once,
(DEFUN FOO () (EVAL '(LOAD-TIME-CONSTANT (INCF *FOO*))))
will increment *FOO* once each time FOO is called.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL, the result must be considered ordinary,
modifiable data. If T, the result is a read-only quantity which may, as
appropriate, be copied into read-only space and/or shared with other
programs. (Because this is a special form, this argument is -not- evaluated
and only the literal symbols T and NIL are permitted.)
Make #,exp be equivalent to (LOAD-TIME-CONSTANT exp T). As such, it
would -always- appear in a for-evaluation position, and never inside quoted
structure.
Rationale:
By making the description of LOAD-TIME-CONSTANT defined as a special
form, we eliminate the need for it to take an environment argument.
By making #, agree with LOAD-TIME-CONSTANT in terms of where it may be
used, we simplify the description of the resulting language.
As discussed in more detail elsewhere in this proposal, the #, syntax
is currently only reliably useful -inside- quoted structure, but this
is unnecessarily complicated for most known uses. Since this proposal
suggests a meaning for #, only -outside- quoted structure, it is an
incompatible change (though not one that would necessarily require
vendors to immediately remove support for existing code).
Cost to Implementors:
This is an incompatible change to the program interface.
The cost is not trivial, but is not particularly high.
Most of the "hard" substrate required to support this proposal
probably already exist; in most cases, what needs to change is
only the way in which the substrate is presented to the
programmer.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
Cost to Users:
Very few users probably use #, right now. A very small amount of code
might need to be rewritten (and recompiled).
The following kinds rewrites exemplify the total amount of work needed
in the few situations that use #, currently:
'#,exp => #,exp
'(... #,exp ...) => #,`(... ,exp ...)
`(... #,exp ...) => `(... ,#,exp ...)
Some user-defined code-walkers would have to be taught about
this new special form. Such changes would also be likely be trivial.
Although change to #, is an incompatible one, vendors would be free to
provide compatibility support for the old behavior for whatever period
they deemed appropriate. #, is equivalent to, but not the same as,
(LOAD-TIME-CONSTANT exp T), so it might in fact expand into
(SYSTEM::LOAD-TIME-CONSTANT exp T) which might be both a macro that
expanded into (LOAD-TIME-CONSTANT exp T). SYSTEM::LOAD-TIME-CONSTANT
might be a magic token which was treated specially within quoted
structure as an unportable extension during a transition period.
Benefits:
Relatively consistent interpreter/compiler treatment of this special form
would be possible.
Pretty printing expressions in which LOAD-TIME-CONSTANT occurred would be
possible.
An expression such as `(... #,(... , ...) ...) would be meaningful.
Manipulating expressions involving uses of LOAD-TIME-CONSTANT would be
possible. Currently, calling READ is enough to trigger resolution of the
constant, so a program doing file-to-file source code rewrites must
either use a special readtable or resign itself to premature resolution
of load time constants.
Expressions involving quoted LOAD-TIME-CONSTANT expressions would be
possible to quote. Currently, the #, feature is syntactic, not semantic,
and so is not sensitive to levels of quotation. You can refer to a
load time constant by writing '#,exp but you cannot refer in turn to that
expression which refers to a load time constant by writing ''#,exp .
Under this NEW-SPECIAL-FORM proposal #,exp and '#,exp and ''#,exp (and
so on) are all usefully distinct.
It would be possible to use , in a #, expression. For example, the
expression:
Examples:
Case NEW-SPECIAL-FORM-1:
(defmacro print-load-timestamp ()
`(print (load-time-constant
`(load-timestamp ,(incf *foo*) ,(get-universal-time))
t)))
(defvar *foo* 0)
(defun test-1 () (print-load-timestamp))
(test-1)
CLtL does not define this situation.
Under this proposal, this code would print
(LOAD-TIMESTAMP 1 <<a-universal-time>>)
at the time the test case is loaded, whether interpreted or compiled.
Subsequent calls to (TEST-1) should print the identical expression.
Currently, no known implementation supports the proposed behavior.
Case NEW-SPECIAL-FORM-2:
(defun test-2 () (print #,'(+ 3 4)))
CLtL does not adequately define this situation.
Under this proposal, this would print (+ 3 4), whether interpreted
or compiled.
Currently, some compilers complain about the syntax, some arrange for
it to print (+ 3 4), and some arrange forit to print the result of
(+ 3 4), or 7.
Case NEW-SPECIAL-FORM-3:
(defun test-3 () (print '#,'(+ 3 4)))
Under CLtL, this would print (+ 3 4).
Under this proposal, the behavior would be undefined.
Currently, most implementations support the proposed behavior.
Case NEW-SPECIAL-FORM-4:
(pprint '(+ x #,(sqrt x)))
prints something re-readable like
(+ X #,(SQRT 2)) or (+ X (LOAD-TIME-CONSTANT (SQRT 2) T))
but not something like
(+ X 1.4142135)
Currently, no implementation is known to already support the
proposed behavior, but in principle it is possible for a valid
implementation to already do so.
Case NEW-SPECIAL-FORM-5:
(defmacro foo (x y)
`(member ,x #,`(foo ,,y baz)))
(macroexpand '(foo *bar*)) => ??
Under CLtL, this situation is not adequately defined.
Under this proposal, the macroexpansion would be
(member foo #,`(foo ,*bar* baz))
Currently, this triggers a read error such as "comma not in backquote"
or "SYSTEM::BACKQUOTE-COMMA undefined function" in most
implementations.
Current practice:
Although most implementations provide a substrate which would allow
program-mediated access to load time evaluation in some way, the language
only defines access to this substrate through the sharpsign read syntax.
Costs of Non-Adoption:
There are numerous possible uses for this facility. Among them are:
* Version control and system building facilities.
* The Common Lisp Object System.
* Language translators which desire to emulate "linking".
While every implementation of Common Lisp could certainly provide an
implementation specific facility capable of supporting such facilities,
portability of such facilities would suffer.
Benefits:
Portability and extended language power. The nature of each proposed
extension is such as to enable other extensions to be added more
gracefully. The Common Lisp Object System is a clear example.
Aesthetics:
These proposals fill a hole in the spectrum of alternatives for
deferring evaluation until a compiled file is loaded. Currently, code
which is read by the reader can arrange for it to be done, as can
top level code, but embedded code cannot. As such, these proposals
clarify and regularize existing parts of the language. Also, by
adding program-accessible entry points to facilities already provided
in a more contrived way, it makes the language easier to use.
Discussion:
There is likely to be some controversy about this proposal, since
there is no universally agreed upon formal processing model for
Common Lisp.
The cleanup committee seems to generally approve of the idea of a
load-time-eval capability, but a number of the details seem to need
ironing out.
Moon supported a previous draft of QUOTED-MAGIC-TOKEN. In this draft,
KMP changed the presentation and also added the READ-ONLY-P argument
in order to make it sit nicely with the alternate proposal,
NEW-SPECIAL-FORM. It's more than slightly possible that after all this
editing, Moon will have some problems with this version and want to
submit a refined draft.
Pitman supports NEW-SPECIAL-FORM.
Rees has expressed strong support for the idea of implementing #, as a
new special form rather than perpetuating the current state of affairs.
He had some input into the high-level content of this proposal, though
he hasn't reviewed any drafts. This paragraph is intended primarily to
incite him to say something definitive one way or the other.
----- End Forwarded Messages -----
∂17-Sep-88 1519 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Sep 88 15:19:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 17 SEP 88 15:17:31 PDT
Date: 17 Sep 88 15:17 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
Aug 88 15:25:52 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Supercedes: <880917-151119-2438@Xerox>
Message-ID: <880917-151731-2443@Xerox>
<change message subject to be consistent with the way that I've asked people
to send them....>
While this seems to be useful functionality, there is a difference between the
LIST type specifiers and the ARRAY type specifiers in that the type of a LIST
object is mutable, e.g.,
(typep x '(list number))
(setf (car y) t)
(typep x '(list number))
is false, while normally, for built in type designators that do not involve
SATISFIES, no side effect operation (other than changing the direct binding of
X) can affect the value of TYPEP for that binding.
Given the mutability of the type designators, I question your assertion "There
is a need in common lisp for more accurate type specifiers
for lists."
I can believe there is a need for a general database interface, and also for a
portable window system.
However, I'm not sure I can admit to knowing what the need here is without some
examples of how it might be used, and where the proposed use is more reasonable,
efficient than the alternative (would you advocate programers say
(typep x '(list number symbol)) instead of
(and (listp x) (numberp (car x)) (symbolp (cadr x)))?
Should it check (null (cddr x))?
Should it be written
(and (consp x) (numberp (car x)) (consp (cdr x)) (symbolp (cadr x)) (null (cddr
x))) ?
I guess I would call it ADDITION instead of COMPATIBLE CHANGE. The distinction
between a CHANGE and an ADDITION in my mind is whether it makes the language
(its description and its implementation) smaller or larger.
----- End Forwarded Messages -----
∂17-Sep-88 1620 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Sep 88 16:19:55 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 460923; Sat 17-Sep-88 15:03:25 EDT
Date: Sat, 17 Sep 88 15:03 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PACKAGE-CLUTTER
To: Scott.Fahlman@B.GP.CS.CMU.EDU, Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 17 Sep 88 02:02 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU,
<880916-154741-1618@Xerox>
Message-ID: <880917150318.6.KMP@GRYPHON.SCRC.Symbolics.COM>
We had extensive discussions of what should go in the USER package a
while back on Common-Lisp. I was an advocate of a pure USER package,
but I eventually decided it was not a battle to be won and have since
come to believe that it is even the right thing for the USER package
to contain implementation-dependent junk.
This time around, I deliberately avoided the issue of the USER package
in this proposal because I think it's a lost cause. If we just tell
people that the USER package's sole purpose in life is for you to have a
package to stand in initially while you type (IN-PACKAGE
'something-else), and if we tell people straight out that no portable
programs should ever expect to run in USER, I think we will be in fine
shape.
I am susceptible to the idea of LISP containing internal symbols, but
I don't want to say that if we don't have to. The reason is that it
does affect what DO-SYMBOLS will do, and so it will be a place where
portable programs will behave differently on a documented package.
It also means that we may get opposition to later extensions because
someone has a LISP::something which collides unfavorably with a
LISP:something that is proposed. All in all, I see no reason for system
programming not to be done in SYSTEM or some such and (DEFUN LISP:xxx ...)
done where appropriate.
Another problem this will avoid is the Zetalisp problem where they have
a few things like EVALHOOK which are both exported functions and internal
(special) variables. The internal variable accidentally shows through
because of an unintended name collision. This sort of thing is easily
fixed once noticed, but is just another error waiting to happen which
could be avoided by programming in another package and accessing LISP
only when you mean to. [Arguably this is yet another indictment of the
package system as a whole. Oh well.]
I hope this doesn't launch into an interminable discussion on this
issue. The bottom line is that I want to keep hands off of USER and I
am prepared to immediately give in on allowing LISP internal symbols if
it looks like a fight will ensue. [Whatever we decide about the
internal/external issue should be explicitly stated to avoid confusion.]
∂17-Sep-88 1622 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Sep 88 16:22:47 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461057; Sat 17-Sep-88 19:21:00 EDT
Date: Sat, 17 Sep 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 5)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880917-151515-2442@Xerox>
Message-ID: <880917192102.0.KMP@GRYPHON.SCRC.Symbolics.COM>
The CL-Compiler committee has been actively discussing this, so I think
we can safely ignore it for the time being.
If they fail to reach closure and submit something to X3J13 in a timely
fashion, I will take care of reviving it here.
∂17-Sep-88 1648 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Sep 88 16:48:42 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA02713g; Sat, 17 Sep 88 15:46:53 PST
Received: by blacksox id AA00896g; Sat, 17 Sep 88 16:44:31 pdt
Date: Sat, 17 Sep 88 16:44:31 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809172344.AA00896@blacksox>
To: masinter.pa@Xerox.COM
Cc: BECKERLE@XX.LCS.MIT.EDU, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 17 Sep 88 15:17 PDT <880917-151731-2443@Xerox>
Subject: Issue: LIST-TYPE-SPECIFIER (Version 1)
Date: 17 Sep 88 15:17 PDT
From: masinter.pa@Xerox.COM
While this seems to be useful functionality, there is a difference between the
LIST type specifiers and the ARRAY type specifiers in that the type of a LIST
object is mutable, e.g.,
(typep x '(list number))
(setf (car y) t)
(typep x '(list number))
is false, while normally, for built in type designators that do not involve
SATISFIES, no side effect operation (other than changing the direct binding of
X) can affect the value of TYPEP for that binding.
If there is going to be an element-type-specialized LIST type
specifier, it should be handled in the same way as
element-type-specialized ARRAY type specifiers. Conceivably, an
implementation could have a special CONS type whose CARs could only
contain elements of a certain type, if such list type specifiers
existed. Isn't there an outstanding cleanup issue regarding array
types? Can you send out the latest version?
∂18-Sep-88 1217 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from FRED.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:17:17 PDT
Received: from FRED.SLISP.CS.CMU.EDU by FRED.SLISP.CS.CMU.EDU; 18 Sep 88 11:09:40 EDT
To: Eric Benson <eb@lucid.com>
cc: masinter.pa@Xerox.COM, BECKERLE@XX.LCS.MIT.EDU,
cl-cleanup@sail.stanford.edu
Subject: Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Your message of Sat, 17 Sep 88 16:44:31 -0700.
<8809172344.AA00896@blacksox>
Date: Sun, 18 Sep 88 11:09:11 EDT
From: Rob.MacLachlan@WB1.CS.CMU.EDU
I agree that it makes sense for a specialized LIST type specifier to be
analogous to ARRAY type specifiers. But this would imply a dramatically
different semantics for LIST type discrimination than the one suggested in
the original proposal.
With array types, only the specalized types chosen by the implementation
are distinct. TYPEP cannot distinguish (on the basis of element type)
between two arrays that were made with different types, but that specialize
to the same type. If (as is probably the case) there is only one
specialized list type, then lists cannot be discriminated at all.
But (if you choose the right array type cleanup) specialized list types
would be useful for declaration, since an implementation *might* have
arbitrary specialized list types:
(typep (elt (the (list number) foo) 3) 'number) <=> T
Rob
∂18-Sep-88 1218 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:18:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461241; Sun 18-Sep-88 15:17:17 EDT
Date: Sun, 18 Sep 88 15:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: LISP-SYMBOL-REDEFINITION
To: masinter.pa@Xerox.COM
cc: cl-cleanup@Sail.stanford.edu, Dieter Kolb <unido!ztivax!kolb@seismo.CSS.GOV>
In-Reply-To: <880917-150250-2427@Xerox>
Message-ID: <19880918191704.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I guess we have to go with LISP-SYMBOL-REDEFINITION:DISALLOW. We
unfortunately have to include the part that prohibits lexically
shadowing (redefining is the wrong word here) functions in the
LISP package with FLET or LABELS or MACROLET (the latter is
missing from the writeup), since research into straightening out
the syntactic environment of macroexpansion isn't mature enough
to put into a standard yet.
You can drop the part about lexically shadowing constants, since the 3rd
paragraph on CLtL p.69 already covers this. It's unclear what the CLtL
sentence about bindings of lexical variables of the same name is
supposed to mean: since CL does not include an UNSPECIAL declaration,
there is no way to express such a binding.
∂18-Sep-88 1234 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:34:46 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461250; Sun 18-Sep-88 15:29:34 EDT
Date: Sun, 18 Sep 88 15:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (version 1)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131932.AA14180@decwrl.dec.com>
Message-ID: <19880918192926.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
TAGBODY-CONTENTS:RESTRICT is fine, although I think I once
saw code that used characters as tags, and I don't see any
obvious reason to disallow that.
∂18-Sep-88 1241 CL-Cleanup-mailer Re: Issue FIXNUM-NONPORTABLE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:41:16 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461255; Sun 18-Sep-88 15:38:57 EDT
Date: Sun, 18 Sep 88 15:38 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue FIXNUM-NONPORTABLE (Version 1)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880915-011455-2083@Xerox>
Message-ID: <19880918193859.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I'm neutral on FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION. I'd be equally
happy with such alternatives as retaining the status quo or eliminating
the FIXNUM type but keeping a way to query what is the most efficient
range of integers. The phrase `use the FIXNUM type specifier in a way
similar to how the "int" type is used in C' really puts me off, since
I have been shafted innumerable times by C's failure to specify any
portable meaning for the "int" type.
∂18-Sep-88 1250 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:50:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461260; Sun 18-Sep-88 15:48:59 EDT
Date: Sun, 18 Sep 88 15:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880914-200045-1692@Xerox>
Message-ID: <19880918194856.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I support DEFSTRUCT-DEFAULT-VALUE-EVALUATION:IFF-NEEDED. All the
discussion about :type is some other issue as far as I am concerned.
∂18-Sep-88 1253 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 12:53:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461261; Sun 18-Sep-88 15:52:06 EDT
Date: Sun, 18 Sep 88 15:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EQUAL-STRUCTURE (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880914-223547-1922@Xerox>
Message-ID: <19880918195209.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 14 Sep 88 22:35 PDT
From: masinter.pa@Xerox.COM
Since this issue was distributed to X3J13 and debated there, in the mail, and on
the Common Lisp mailing list, we probably need to report on our disposition of
it.
My personal opinion is that we cannot fix EQUAL and EQUALP, and we are better
off leaving them alone. I would like to withdraw the issue; I don't see a need
for a "status quo" clarification.
I agree.
∂18-Sep-88 1323 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 13:23:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461285; Sun 18-Sep-88 16:22:13 EDT
Date: Sun, 18 Sep 88 16:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19880918202212.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I decided to write this up since it has been discussed endlessly
without a formal proposal, and to make it clear that it is
independent of the pending DECLARATION-SCOPE issue.
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
Category: ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Problem description:
Most people interpret CLtL's phrase "(TYPE type var1 var2 ...) affects
only variable bindings" to mean that code such as the following is
not valid Common Lisp, because a type declaration can only be attached
to a binding, not used free.
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Proposal (DECLARE-TYPE-FREE:ALLOW):
Change the phrase "affects only variable bindings" to "concerns variable
bindings." Clarify that this makes the above program a valid program
and that this kind of declaration means the same thing as inserting
THE in every reference to the variable and every setq of the variable.
Rationale:
There is no reason to forbid this usage, and people have often asked
for it.
Current practice:
I don't know.
Cost to Implementors:
None, it is valid to ignore type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
The above example will not have to be written in the following silly way,
which only works if x and y are used read-only:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(let ((x x) (y y))
(declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Esthetics:
Yes.
Discussion:
None.
∂18-Sep-88 1343 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Sep 88 13:43:41 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02875g; Sun, 18 Sep 88 12:41:59 PST
Received: by bhopal id AA11384g; Sun, 18 Sep 88 13:41:25 PDT
Date: Sun, 18 Sep 88 13:41:25 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809182041.AA11384@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu, unido!ztivax!kolb@seismo.CSS.GOV
In-Reply-To: masinter.pa@Xerox.COM's message of 17 Sep 88 15:02 PDT <880917-150250-2427@Xerox>
Subject: LISP-SYMBOL-REDEFINITION
Instead of disallowing all symbols in the lisp package, why not have a
global registry (list, hash-table, etc.) of symbols whose redefinition
is disallowed, initialized in an implementation-specific manner to any
superset of the symbols in the lisp package? This has two advantages:
(1) Users would have a simple mechanism to protect their own
definitions, e.g.
(SETF (GETHASH 'MY-CAR *REDEFINTIONS-RESTRICTED*) T)
or with a more elaborate mechanism:
(SETF (GETHASH 'MY-CAR *REDEFINTION-RESTRICTIONS*)
'((:TRACE :ALLOWED) (:DEFVAR :ALLOWED) (:OTHERWISE :FORBIDDEN)))
(2) By temporarily removing a symbol from the registry you could enable
it for redefinition (e.g., while patching bugs or experimenting).
I also think the behavior of TRACE could be constrained somewhat more
than is stated. E.g., TRACE could be explicitly required to avoid
introducing infinite loops or recursions into standard CL functions,
if necessary by failing to trace certain functions. TRACE could also
be required to indicate to the user when functions in the registry are
being traced. But perhaps this is just common sense and/or purely
environmental issues...
jlm
∂18-Sep-88 1432 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 18 Sep 88 14:32:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461308; Sun 18-Sep-88 17:31:18 EDT
Date: Sun, 18 Sep 88 17:31 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: HASH-TABLE-PACKAGE-GENERATORS
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, cliter@sail.stanford.edu
In-Reply-To: <880916-015507-3866@Xerox>
Message-ID: <19880918213119.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 16 Sep 88 01:55 PDT
From: masinter.pa@Xerox.COM
There was an interesting interchange on this proposal back in May, but no good
resolution. Would someone care to review the messages and extract a revised
proposal? I think we can't ignore locking because there is a way to implement
iterators without locking. Moon says "You need to be able to wrap something
around the whole iteration,
not merely have a function that performs the next step in the iteration...."
JonL and I are having a private discussion about this.
Or is this issue moot? E.g., if implementations are required to provide LOOP and
OSS (even as a loadable libraries), is there any purpose served in also making
the lowlevel mechanism visible?
Yes. It's clear that the community is not going to agree on one single
iteration language, which makes it likely that ongoing research on ways
of expressing iteration will continue. Having a standard low-level
mechanism so that the "blessed" iteration packages can be written in a
portable way, but refusing to publish its name, would be an unwarranted
deprecation of ongoing research.
∂18-Sep-88 1632 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 18 Sep 88 16:32:17 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 18 SEP 88 16:30:46 PDT
Date: Sun, 18 Sep 88 16:30 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: LOAD-TIME-EVAL (Version 5)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <880917192102.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880918233023.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Sat, 17 Sep 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The CL-Compiler committee has been actively discussing this, so I think
we can safely ignore it for the time being.
If they fail to reach closure and submit something to X3J13 in a timely
fashion, I will take care of reviving it here.
Given the current X3J13 schedule, what does timely mean? Is there
reason to believe the compiler committee will arrive in Washington with
a detailed proposal that they want the full committee to vote on? If
not, the cleanup committee should probably generate its own proposal
now.
-------
∂18-Sep-88 2235 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Sep 88 22:35:33 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA03000g; Sun, 18 Sep 88 21:32:29 PST
Received: by blacksox id AA00906g; Sun, 18 Sep 88 22:30:10 pdt
Date: Sun, 18 Sep 88 22:30:10 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809190530.AA00906@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sun, 18 Sep 88 16:22 EDT <19880918202212.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
For current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already. The production mode
of the compiler gives a warning that this usage is an extension to
Common Lisp. The interpreter and the development mode of the compiler
don't pay any attention to declarations except SPECIAL, INLINE and
NOTINLINE.
∂19-Sep-88 0853 CL-Cleanup-mailer Re: Issue: LOAD-TIME-EVAL (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88 08:53:27 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461540; Mon 19-Sep-88 11:51:26 EDT
Date: Mon, 19 Sep 88 11:51 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-TIME-EVAL (Version 5)
To: Gregor.pa@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA@Xerox.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880918233023.5.GREGOR@PORTNOY.parc.xerox.com>
Message-ID: <880919115114.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Sun, 18 Sep 88 16:30 PDT
From: Gregor.pa@Xerox.COM
Date: Sat, 17 Sep 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The CL-Compiler committee has been actively discussing this, so I think
we can safely ignore it for the time being.
If they fail to reach closure and submit something to X3J13 in a timely
fashion, I will take care of reviving it here.
Given the current X3J13 schedule, what does timely mean? Is there
reason to believe the compiler committee will arrive in Washington with
a detailed proposal that they want the full committee to vote on? If
not, the cleanup committee should probably generate its own proposal
now.
I'm an observer, not an activist, on the CL-Compiler list. All I can
say is that there is mail batting around about every other day on the
topic, and it seems fair to allow them that opportunity. I will forward
your concerns to that list and we can see how they respond.
∂19-Sep-88 0933 CL-Compiler-mailer Issue: LOAD-TIME-EVAL
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88 09:32:52 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461592; Mon 19-Sep-88 12:29:51 EDT
Date: Mon, 19 Sep 88 12:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL
To: sandra%defun@cs.utah.edu
cc: CL-Compiler@SAIL.Stanford.EDU, CL-Cleanup@SAIL.Stanford.EDU
References: <8809191543.AA00753@defun.utah.edu>,
<19880918233023.5.GREGOR@PORTNOY.parc.xerox.com>,
<880917-151515-2442@Xerox>
Message-ID: <880919122944.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Fyi, the following discussion recently took place on CL-Cleanup...
Date: 17 Sep 88 15:15 PDT
From: masinter.pa@Xerox.COM
To: CL-Cleanup@SAIL.Stanford.EDU
I think this is a moderately useful issue to be resolved if the compiler
committee hasn't done so. I'm not on cl-compiler so I don't know what, if any,
progress has been made on the numerous issues that were deferred to them. Was
this one of them?
-----
Date: Sat, 17 Sep 88 19:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
To: CL-Cleanup@SAIL.Stanford.EDU
The CL-Compiler committee has been actively discussing this, so I think
we can safely ignore it for the time being.
If they fail to reach closure and submit something to X3J13 in a timely
fashion, I will take care of reviving it here.
-----
Date: Sun, 18 Sep 88 16:30 PDT
From: Gregor.pa@Xerox.COM
To: CL-Cleanup@SAIL.Stanford.EDU
Given the current X3J13 schedule, what does timely mean? Is there
reason to believe the compiler committee will arrive in Washington with
a detailed proposal that they want the full committee to vote on? If
not, the cleanup committee should probably generate its own proposal
now.
∂19-Sep-88 1224 CL-Cleanup-mailer Issue: RANGE-OF-COUNT-KEYWORD
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 12:24:32 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA15206; Mon, 19 Sep 88 12:23:09 PDT
Date: Mon, 19 Sep 88 12:23:09 PDT
Message-Id: <8809191923.AA15206@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: RANGE-OF-COUNT-KEYWORD
After asking both implementors and users within DEC, I got quite a
variety of opinions. However, I believe the plurality was in favor
of treating a negative :count value as an error. [Allowing only
NIL or integers was just fine, of course.]
So even though I personally prefer the proposal as written, I think I
should support a slightly different version which defines negative
values of :COUNT to be in error.
---Walter
∂19-Sep-88 1236 CL-Cleanup-mailer Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 12:36:21 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA16065; Mon, 19 Sep 88 12:34:58 PDT
Date: Mon, 19 Sep 88 12:34:58 PDT
Message-Id: <8809191934.AA16065@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: DESCRIBE-INTERACTIVE (Version 1)
I'll agree with Larry that reading the description of DESCRIBE seems to
imply a similarity with PRINT that would not make it desirable to do any
input. As several people have pointed out, that's why there's INSPECT.
On the other hand, I don't the standard should be too prescriptive on
what the debugging tools (25.3 of CLtL) may and may not do.
---Walter
∂19-Sep-88 1259 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 12:59:20 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA17936; Mon, 19 Sep 88 12:57:56 PDT
Date: Mon, 19 Sep 88 12:57:56 PDT
Message-Id: <8809191957.AA17936@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: EQUAL-STRUCTURE
Although I agree that we should keep the "status quo", I think a clarification
is still in order. I believe CLtL isn't clear in saying that EQUAL does
not look at the slots of a structure in determining equality--i.e., that
EQUAL on user-defined structures is the same as EQ.
---Walter
∂19-Sep-88 1308 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Sep 88 13:07:58 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA11413; Mon, 19 Sep 88 14:06:37 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA00963; Mon, 19 Sep 88 14:06:17 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809192006.AA00963@defun.utah.edu>
Date: Mon, 19 Sep 88 14:06:15 MDT
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com
Cc: cl-cleanup@sail.stanford.edu
Since the cleanup committee is expecting us to do something on this
issue promptly, I've gone ahead with the sketch for the new proposal
on this issue that I started on last week. Not having heard anything
back from my last request for comments (are all of you compiler people
asleep?), I've rather arbitrarily decided upon allowing the
interpreter to perform multiple evaluations, and warning users that
they can get into trouble by performing destructive operations.
Because the writeup on this issue is already so long, I've only
included the most relevant parts here. If I hear some favorable
feedback on what I've got so far, I'll finish it up the rest of it.
Otherwise, I will turn the issue back over to Pitman and the cleanup
committee in the hopes that they will be able to make more progress on
it than we have.
-Sandra
Proposal (LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM):
Add a new special form, LOAD-TIME-VALUE, which has the following
contract:
LOAD-TIME-VALUE form &optional read-only-p [Special Form]
All processing of the <form> is deferred until the expression is
in the "runtime" environment. Once that environment is available,
<form> is evaluated in the null lexical environment and the result
is returned; the result may also be saved for immediate access by
the program on subsequent evaluations.
LOAD-TIME-VALUE is, in effect, a promise by the user that multiple
evaluations of <form> will return values that are semantically
equivalent (although not necessary EQ).
In the interpreter, (LOAD-TIME-VALUE <form>) is equivalent to
(VALUES (EVAL (QUOTE <form>))). However, it is permissible for
an implementation to perform the evaluation of <form> only once for
each reference to the surrounding LOAD-TIME-VALUE expression and to
cache that value for subsequent use; this may be done by a
preprocessor, for example.
If a LOAD-TIME-VALUE expression appears within a function compiled
with COMPILE, the compiler may either evaluate the <form> or use
a previously cached value. It is guaranteed that the <form> will
not be evaluated again at runtime; instead, the result of the
compile-time evaluation is treated as an immediate quantity in the
compiled code.
If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, the compiler
arranges for all semantic processing of <form> (including macro
expansion) to occur at load time in a null lexical environment. It
is guaranteed that the evaluation of <form> will take place only once
when the file is loaded, but the order of evaluation with respect to
the "evaluation" of top-level forms in the file is unspecified.
Note that, in interpreted code, there is no guarantee as to when
evaluation of <form> will take place, or the number of times the
evaluation will be performed. This is intentionally similar to the
freedom which implementations are given for when macros are expanded
in interpreted code.
Implementations must guarantee that each reference to a LOAD-TIME-VALUE
expression within a form to be evaluated results in at least one
evaluation of <form>. It is not permissible to "collapse" either
multiple references to the same (EQ) LOAD-TIME-VALUE expression or
EQUAL expressions. Note that, in the case of a LOAD-TIME-VALUE form
appearing in a quoted expression passed to EVAL, each call to EVAL must
result in a new evaluation of <form>. For example,
(DEFVAR X 0)
(DEFUN FOO () (EVAL '(LOAD-TIME-VALUE (INCF X))))
is guaranteed to increment X each time FOO is called, while
(DEFUN FOO () (LOAD-TIME-VALUE (INCF X)))
may cause X to be evaluated only once.
The READ-ONLY-P argument designates whether the result can be considered
read-only constant. If NIL, the result must be considered ordinary,
modifiable data. If T, the result is a read-only quantity which may, as
appropriate, be copied into read-only space and/or shared with other
programs. (Because this is a special form, this argument is -not- evaluated
and only the literal symbols T and NIL are permitted.)
Note that, since successive evaluations of the same LOAD-TIME-VALUE
expression may or may not result in an evaluation which returns a
"fresh" object, users cannot rely upon either the persistence or
absence of destructive side-effects. In such cases, it is safest to
explicitly initialize the object returned by LOAD-TIME-VALUE.
Make #,exp be equivalent to (LOAD-TIME-VALUE exp T). As such, it
would -always- appear in a for-evaluation position, and never inside quoted
structure.
Rationale:
By making the description of LOAD-TIME-VALUE defined as a special
form, we eliminate the need for it to take an environment argument.
By making #, agree with LOAD-TIME-VALUE in terms of where it may be
used, we simplify the description of the resulting language.
As discussed in more detail elsewhere in this proposal, the #, syntax
is currently only reliably useful -inside- quoted structure, but this
is unnecessarily complicated for most known uses. Since this proposal
suggests a meaning for #, only -outside- quoted structure, it is an
incompatible change (though not one that would necessarily require
vendors to immediately remove support for existing code).
Allowing the same LOAD-TIME-VALUE to cause its nested <form> to be
evaluated more than once makes it much simpler to implement in
interpreters which do not perform a preprocessing code walk. It also
makes the rules for the time of its processing analogous to those
for macro expansion.
The prohibition against collapsing of shared or EQUAL LOAD-TIME-VALUE
expressions prevents problems that could result by performing destructive
side-effects on a value that is referenced in more than one place.
Cost to Implementors:
This is an incompatible change to the program interface.
The cost is not trivial, but is not particularly high.
Most of the "hard" substrate required to support this proposal
probably already exist; in most cases, what needs to change is
only the way in which the substrate is presented to the
programmer.
Some code-walkers would have to be taught about this new
special form. Such changes would likely be trivial.
For implementations that do not use a preprocessor in the interpreter,
the simplest technique for implementing LOAD-TIME-VALUE would be to
always evaluate <form> without caching the value. Implementations
that do use a preprocessing code walk could be extended to do the
evaluation at the same time they do macro expansion.
-------
∂19-Sep-88 1429 CL-Cleanup-mailer Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:28:51 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA02472; Mon, 19 Sep 88 17:28:32 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA08987; Mon, 19 Sep 88 17:30:10 EDT
Message-Id: <8809192130.AA08987@mist.UUCP>
To: David N Gray <Gray%DSG.csc.ti.com@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
In-Reply-To: Your message of Thu, 15 Sep 88 15:05:41 -0500.
<2799345941-16254274@Kelvin>
Date: Mon, 19 Sep 88 17:30:08 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I think this could be specified in a portable way. Suppose we say that
the second argument of REQUIRE is a string or list of strings. Each
string must begin with a letter and contain only letters and digits. Then
if the indicated module is not present, REQUIRE calls the loader, using
each string as the name field of a pathname, defaulting the version to
:NEWEST and the rest of the pathname components to be the same as the file
in which the REQUIRE form was found, truncating the name if necessary to
make it legal. In other words, it loads additional files from the same
directory. I think this would work on all five of the file systems that I
use. Would it be useful enough to be worthwhile?
This works iff you believe that all of the files are in the same
directory. I find that highly unlikely for any large system and would
oppose this as it seems like an attempt to standardize an at best
old-fashioned way to organize source files.
∂19-Sep-88 1431 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:31:14 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA02504; Mon, 19 Sep 88 17:30:54 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA09008; Mon, 19 Sep 88 17:32:33 EDT
Message-Id: <8809192132.AA09008@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 2)
Date: Mon, 19 Sep 88 17:32:30 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: REQUIRE-PATHNAME-DEFAULTS
References: *MODULES*, PROVIDE, REQUIRE, pp 188-191
LOAD, pp 426-427
Category: CHANGE
Edit history: Version 1 by Pierson 9/13/88
Version 2 by Pierson 9/19/88, change PROVIDE stuff per comments
Status: For Internal Discussion
Problem description:
PROVIDE and REQUIRE are a dual-purpose pair of functions that attempt
to provide multi-file Common Lisp programs with a single mechanism to
detect and correct incorrect load sequences. These functions were
also designed to be used for general file inclusion in Common Lisp.
Unfortunately, the file loading feature of REQUIRE is specified such
that it is inherently non-portable and environment dependent.
The instructions on CLtL pp. 189-191 on the placement of PROVIDE and
REQUIRE don't work because they ignore interactions with LOAD. If
PROVIDE is placed at the head of a file which fails to load correctly,
the module will be incorrectly recorded as loaded. If PROVIDE is
placed at the end of the file, as is the unofficial current practice
in some groups, it is not possible to REQUIRE a file that REQUIREs the
current file; thus mutually dependent modules cannot be correctly
defined.
Proposal (REQUIRE-PATHNAME-DEFAULTS:DECLARATIVE):
Remove the second argument from REQUIRE. Change the description of
REQUIRE to:
The REQUIRE function tests whether a module is already present
(using a case-sensitive comparison); if the module is not present,
REQUIRE signals a correctable error of type REQUIRE-ERROR. The
error can be corrected by loading the appropriate file(s).
Note that there is no requirement that a module consist of exactly one
file.
Change the description of PROVIDE to:
"The PROVIDE function adds a new module name to the list of
modules maintained in the variable *MODULES* and possibly performs
other implementation-dependant actions to indicate that the module
in question has been loaded."
(There is no need to make a corresponding change to the definition of
REQUIRE, because it doesn't mention *MODULES*.)
Add a new second paragraph to the section on LOAD (CLtL 23.4):
"Top level PROVIDE functions in files being loaded are handled
specially. The PROVIDE is executed in a temporary environment
such that the module will appear to have been loaded during the
remainder of the load of the current file and any files loaded,
whether directly or by REQUIRE, during the loading of the current
file. If an error occurs during the loading of the current file,
all modules PROVIDEd during the load of the current file will be
forgotten. Otherwise, all these modules will be "confirmed" at
this level of nested loading. (Note that an implementation which
uses *MODULES* as the only loaded module database can support all
of this by simply rebinding *MODULES* appropriately internally
and pushing the new modules onto the old binding at the end.)"
Test Cases/Examples:
(REQUIRE 'fft)
Would still be legal.
(REQUIRE 'fft "fft")
Would no longer be Common Lisp.
Rationale:
The file loading feature of REQUIRE is non-portable. Since we can't
figure out an acceptable portable solution, the feature should be
flushed. Making REQUIRE signal a correctable error gives the user an
easy out in interactive situations.
Current practice:
All implementations that I know of currently support a second argument
to REQUIRE. Lucid and KCL use the second argment at the pathname to
load relative to the current working directory.
Cost to Implementors:
All currently conforming implementations will have to make a small
change.
Cost to Users:
Any (non-portable) user programs that rely on the current behaviour of
REQUIRE will have to change. On the other hand, porting Common Lisp
programs from one system to another may well be simplified because
REQUIRE errors will always correctable.
Cost of non-Adoption:
Part of the documented functionality of REQUIRE will continue to
unavailable to portable (and many non-portable) programs.
Benefits:
PROVIDE and REQUIRE will be clearly restricted to a portable,
checking role.
Aesthetics:
This simplifies the language by removing an environment-dependent
feature.
Discussion:
Pierson supports this proposal.
This proposal creates an asymmetry in the handling of *MODULES* that
may bother some people.
Several people would like to simply eliminate PROVIDE and REQUIRE from
the language and either leave this language space empty or provide a
portable DEFSYSTEM standard. Others believe that PROVIDE and REQUIRE
are useful as a safety-net even in the presence of DEFSYSTEM. This
proposal attempts to reduce PROVIDE and REQUIRE to a well-defined
safety-net and leaves the question of DEFSYSTEM to a separate
proposal (which I don't intend to write).
∂19-Sep-88 1438 CL-Cleanup-mailer Re: CL-CLEANUP committee mtg's
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:38:49 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 14:19:24 PDT
Date: 19 Sep 88 14:19 PDT
From: masinter.pa@Xerox.COM
Subject: Re: CL-CLEANUP committee mtg's
To: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU
cc: cl-cleanup@Sail.stanford.edu
Message-ID: <880919-141924-2267@Xerox>
In response to a request for clarification about how the cleanup committee is
organized:
I usually only announce cleanup committee meetings to people on the cleanup
mailing list, since efficiency would suffer if attendees lacked context. The
cleanup committee is open to people who want to work on it. I've generally
discouraged passive observers.
I've suggested a cleanup committee meeting Monday 10-10 from 9:30 to 12:30, and
have heard no complaints so far.
Decisions are made by consensus when we can get it. Sometimes the only consensus
is "we all agree that this writeup fairly presents the pros and cons of the
issue". We've brought things for a vote to the general X3J13 where only one
committee member was in favor of the proposal.
∂19-Sep-88 1439 CL-Editorial-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 14:38:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03479g; Mon, 19 Sep 88 13:37:14 PST
Received: by bhopal id AA14744g; Mon, 19 Sep 88 14:36:41 PDT
Date: Mon, 19 Sep 88 14:36:41 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809192136.AA14744@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com,
CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 12 Sep 88 20:25 EDT <19880913002519.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
re: Proposal (HASH-TABLE-KEY-MODIFICATION:SPECIFY):
. . .
I fear this is far too vague to be a cleanup proposal, however well-
motivated it may have been. Indeed, there was a discussion of this topic
on Common-Lisp@SU-AI about a year ago (as well as a few related msgs quite
recently), but the upshot of all the discussion was merely to "enlighten"
more of the community about the techniques of hashing in general. I think
we should limit our efforts in this arena at giving advice to editors
(such as Steele, and Chapman, etc.) on how to explain the consequences of
some typical hashing techniques.
First, there is no generally agreed-upon notion of what a "component" is;
so the part where you say:
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.
In EQUAL hash tables, it is an error to modify a component of a key.
isn't saying anything usable; or if it is, then it is something already
understood via channels outside this proscription. Furthermore, it could
bog us down for months if we tried to specify "component" exactly. For
example, is the bit-field (byte 3 5) of a fixnum X a "component" of X?
Second, the "rule":
If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function. If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.
is completely inadequate. You might as well say that it is an error to
modify the components of list elements for any list that is passed to a
sequence function with a :test argument of EQUAL. What you probably meant
to say, in the hash-table context, is:
... it is an error to modify an object used as key in a hash table
iff such modification affects either (1) the outcome of equivalence
test used by the hash-table, or (2) the structure of the collision
chains built up in the hash table [note that SXHASH, or a substitute
therefor, may be involved in the structure of collision chains].
[There might have to be a line saying that the :test component of a hash-
table is always an equivalence relation.] However, CLtL neither specifies
that hash-tables must use some "collision chain" technique -- alists appear
to be a fully conforming implementation (albeit sloooow) -- nor does is even
specify that any such collision tecnhique must be based on the output of
SXHASH. About the most it says is that hashing should be "fast".
Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
even mention collision chains.
An implementational note *might* be worth mentioning in the document
standard about how the historical intent of EQ/EQL tables was in fact
to limit the information obtained from an object to merely the pointer
itself (i.e., it's address), and that this usually meant faster hashing
(in MacLisp, for example). But with the spread of copying GC's (stop-
and-copy, generational, etc) this kind of dependency limitation forces
some very odd behaviour on the memory-management subsystem, such as the
need for rehashing after GC's, etc. I really know of cases where an EQL
table was grossly slower than an EQUAL table, simply because it forced so
much more attention from the memory-management subsystem.
Typically, only very "introspective" code needs to know whether, say, two
strings are EQL rather EQUAL; and very often even experienced users make
the mistake of thinking that EQ means speed and EQUAL means sloth.
Certainly no one using Common Lisp should prefer an EQ/EQL table over
an EQUAL one, unless he is actually concerned with the implementational
identity of objects [such as in system code doing circularity checks,
or "constants" coalescing, or macromemo-izing, etc.].
I think the gist of these last two paragraphs is something that the
standards editors could try to work into the next chapter on Hash-Tables
(and possibly something about "collision chains" being a frequent part
of hash-tables). This would be preferable to having the cleanup sub-
committee try to solve the unsolvable problem of anticipating every
possible consequence of every possible implementation technique for
hash-tables.
-- JonL --
∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: NTH-VALUE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:05:09 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 14:43:31 PDT
Date: 19 Sep 88 14:43 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: NTH-VALUE
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of 12 Sep 88 16:06
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880919-144331-2329@Xerox>
My belief is that as long as there is some proponent for a proposal we are
better off submitting it with the recommendation that it not be adopted than
just dropping it. I think the mail is clear that both Kent and Dan are
interested in seeing this carried forward. I'm neutral on it, but I've had on
more than one occasion had to write
(multiple-value-bind (ignore value) (form) (declare (ignore ignore)) value)
to get what I wanted, so that this is mildly interesting to me.
∂19-Sep-88 1505 CL-Cleanup-mailer Issue writeups
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:05:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 14:52:11 PDT
Date: 19 Sep 88 14:52 PDT
From: masinter.pa@Xerox.COM
Subject: Issue writeups
To: cl-cleanup@sail.stanford.edu
Message-ID: <880919-145211-2356@Xerox>
Two reminders for those working on cleanup issue writeups:
a) please remember that we are describing changes to the *langauge* and not
changes to CLtL. While we give reference to CLtL as the previous specification,
the proposals will be clearer if you say "Change the language so that FROB
accepts a BAZ" than if you say "Change the wording on P 515 so that it says
'FROB can accept a BAZ'".
This helps us separate out those things that are properly the domain of the
editorial committee and not this group.
b) Please avoid the "blow-by-blow" accounts in the "Discussion" section, e.g.,
"KDL likes this, kind of. HMP things it stinks, mainly. PDQ said 'Well, I like
it, but only on Thursdays.'"
Try to keep the discussion in terms of the language and external characteristics
of it, wherever possible. Testimonials have there place where they cannot be
avoided, but generally the proposals will have more impact if we can discussion
the issues on their own merits.
∂19-Sep-88 1505 CL-Cleanup-mailer Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:05:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 15:02:27 PDT
Date: 19 Sep 88 15:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Mon, 19 Sep 88 14:36:41
PDT
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU,
GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
Message-ID: <880919-150227-2389@Xerox>
My immediate reaction to your message was that it was a hasty disqualification
of an otherwise valid issue for the cleanup committee to address.
Certainly the issue needs to be addressed. If Kathy things it is reasonable to
do so within the scope of the editorial board, I'm happy to allow it to be
addressed there.
However, it does seem like an issue that can be well-specified without resorting
to a discussion of copying garbage collectors and collision chains in the
specification.
∂19-Sep-88 1512 CL-Cleanup-mailer Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:11:53 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04485; Mon, 19 Sep 88 18:11:43 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA09183; Mon, 19 Sep 88 18:13:20 EDT
Message-Id: <8809192213.AA09183@mist.UUCP>
To: "vanroggen%aitg.DEC@decwrl.dec.com"@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: STANDARD-INPUT-INITIAL-BINDING (version 8)
In-Reply-To: Your message of Wed, 14 Sep 88 07:20:09 -0700.
<8809141420.AA02973@decwrl.dec.com>
Date: Mon, 19 Sep 88 18:13:14 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
This looks pretty good, except I think many implementations would
prefer not to have a requirement that *TERMINAL-IO* be a Common Lisp
stream. Already most implementations bind *TERMINAL-IO* to
implementation dependent streams, and I think in this case it's
best to continue the status quo.
*TERMINAL-IO* obviously has to be bound to a Common Lisp stream in
that it has to work for all of the Common Lisp IO functions, etc. that
take stream arguments. Other than that, I don't see that the proposal
prevents *TERMINAL-IO* from being bound to an implementation dependent
stream type.
∂19-Sep-88 1542 CL-Cleanup-mailer Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88 15:41:47 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 461963; Mon 19-Sep-88 18:39:45 EDT
Date: Mon, 19 Sep 88 18:39 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-KEY-MODIFICATION (Version 1)
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU, GLS@Think.com, CL-Editorial@SAIL.STANFORD.EDU
In-Reply-To: <8809192136.AA14744@bhopal>
Message-ID: <19880919223934.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 19 Sep 88 14:36:41 PDT
From: Jon L White <jonl@lucid.com>
....
First, there is no generally agreed-upon notion of what a "component" is;
so the part where you say:
In EQ and EQL hash tables, components of a key may be freely modified
with no effect on the table.
In EQUAL hash tables, it is an error to modify a component of a key.
isn't saying anything usable; or if it is, then it is something already
understood via channels outside this proscription.
It's true that "component" is a vague notion. As elaborated on later in
the proposal, "component" should be defined in terms of the test function.
Maybe this initial vague language should just be abandoned.
Furthermore, it could
bog us down for months if we tried to specify "component" exactly. For
example, is the bit-field (byte 3 5) of a fixnum X a "component" of X?
Who cares, since Common Lisp does not provide any way to modify fixnums.
Second, the "rule":
If implementations define additional acceptable values for the :TEST
argument to MAKE-HASH-TABLE, the rule is that it is an error to modify
a component of a key if and only if that component affects the test
function. If that component cannot affect the test function, the hash
table's operation must not be affected by modifying the component.
is completely inadequate. You might as well say that it is an error to
modify the components of list elements for any list that is passed to a
sequence function with a :test argument of EQUAL.
That's precisely what I would have said, if sequence functions were
permitted to create auxiliary data structures that encache information
about their arguments from one call to the next. Since they are not
(although this is only implied by CLtL), there is no need to impose
such a restriction on their callers.
What you probably meant
to say, in the hash-table context, is:
... it is an error to modify an object used as key in a hash table
iff such modification affects either (1) the outcome of equivalence
test used by the hash-table, or (2) the structure of the collision
chains built up in the hash table [note that SXHASH, or a substitute
therefor, may be involved in the structure of collision chains].
[There might have to be a line saying that the :test component of a hash-
table is always an equivalence relation.] However, CLtL neither specifies
that hash-tables must use some "collision chain" technique -- alists appear
to be a fully conforming implementation (albeit sloooow) -- nor does is even
specify that any such collision tecnhique must be based on the output of
SXHASH. About the most it says is that hashing should be "fast".
Unfortunately, nowhere does the discussion of HASH-TABLE-KEY-MODIFICATION
even mention collision chains.
I vehemently disagree with this, and I think you're being completely
wrong-headed. The point of the proposal was to state what are the
requirements on Common Lisp programs so that they will be portable
to all implementations of hash tables. The internal details of hash
tables in some particular implementation are not relevant; furthermore,
discussing them can only mislead users into writing non-portable
programs. What I meant to say was precisely what I did say. I agree
that an editor could find more precise language than "affect the
test function" by which I mean "change the answer returned by the
test function."
An implementational note *might* be worth mentioning in the document
standard about how the historical intent of EQ/EQL tables was in fact
to limit the information obtained from an object to merely the pointer
itself (i.e., it's address), and that this usually meant faster hashing
(in MacLisp, for example). But with the spread of copying GC's (stop-
and-copy, generational, etc) this kind of dependency limitation forces
some very odd behaviour on the memory-management subsystem, such as the
need for rehashing after GC's, etc. I really know of cases where an EQL
table was grossly slower than an EQUAL table, simply because it forced so
much more attention from the memory-management subsystem.
Typically, only very "introspective" code needs to know whether, say, two
strings are EQL rather EQUAL; and very often even experienced users make
the mistake of thinking that EQ means speed and EQUAL means sloth.
Certainly no one using Common Lisp should prefer an EQ/EQL table over
an EQUAL one, unless he is actually concerned with the implementational
identity of objects [such as in system code doing circularity checks,
or "constants" coalescing, or macromemo-izing, etc.].
I think the gist of these last two paragraphs is something that the
standards editors could try to work into the next chapter on Hash-Tables
(and possibly something about "collision chains" being a frequent part
of hash-tables).
I agree that it might be interesting to have a book that discusses the
performance tradeoffs in hash tables. I don't think that has anything to
do with the issue at hand, which is to define what characteristics of hash
tables may or may not be assumed by portable programs.
This would be preferable to having the cleanup sub-
committee try to solve the unsolvable problem of anticipating every
possible consequence of every possible implementation technique for
hash-tables.
If you thought that's what the HASH-TABLE-KEY-MODIFICATION issue was
about, you misunderstood it. It's about defining whether portable
programs may or may not perform side effects on objects used as
keys of hash tables, and which side-effects can be performed. I
can see it needs to be written up in a form that is less easy
to misunderstand. If I have time, which is not too likely, I'll
do that, otherwise I'll just forget it.
∂19-Sep-88 1618 CL-Cleanup-mailer Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 16:17:56 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 16:03:15 PDT
Date: 19 Sep 88 16:01 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PATHNAME-COMPONENT-CASE (Version 1)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Fri, 22 Jul 88 09:40:41
EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880919-160315-2575@Xerox>
This issue had a flurry of discussion back in July, but I have no record of any
traffic since.
As the issue says "This does not solve the whole pathname problem, but it does
improve the situation for a clearly defined set of very common problems."
Is it worth putting this requirement on PATHNAME implementations if it doesn't
really improve portability of real applications?
My general experience is that even within a single application, users have
difficulty writing portable code because of a lack of "logical" pathnames --
they write code that reads in files and data from servers that don't exist when
at the site to which the code is shipped. This stuff, about case, doesn't seem
to have much real effect.
The only examples in the issue writeup relate to multiple-file-system hosts
where the host file system conventions are visible to the Lisp itself.
(Sometimes, the file access protocol itself will map file names into a 'native'
naming convention before Lisp even sees it.)
∂19-Sep-88 1636 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 16:36:17 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 19 SEP 88 16:23:42 PDT
Date: 19 Sep 88 16:23 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
PATHNAME-WILD
To: cl-cleanup@sail.stanford.edu
Message-ID: <880919-162342-2642@Xerox>
I think it might be worthwhile to organize the pathname issues by operating
system, e.g., What's the right way for CL to talk to Unix-like file systems? To
Mac-like file systems? To VMS-like file systems?
At least for PATHNAME-COMPONENT-CASE, PATHNAME-CANONICAL-LIST, PATHNAME-WILD,
PATHNAME-TYPE-SPECIFIC.
There seem to be more PATHNAME issues than file-naming conventions. Further, it
seems more important to reach convergence within an operating system than across
them; for example, there's no good reason why the 7 different CLs available for
various UNIX systems should treat file names differently, or those within the
Mac world should treat those names differently. If we can get convergence among
implementors of CL within OS classes, we might well be able to sort out which
things are really different because the host OS is different?
What do you think?
∂19-Sep-88 1658 CL-Cleanup-mailer Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 19 Sep 88 16:58:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462037; Mon 19-Sep-88 19:57:12 EDT
Date: Mon, 19 Sep 88 19:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-SUBDIRECTORY-LIST, PATHNAME-COMPONENT-CASE,
PATHNAME-WILD
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880919-162342-2642@Xerox>
Message-ID: <19880919235657.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 19 Sep 88 16:23 PDT
From: masinter.pa@Xerox.COM
I think it might be worthwhile to organize the pathname issues by operating
system, e.g., What's the right way for CL to talk to Unix-like file systems?
What do you think?
I think that focussing the pathname issues by using specific operating
systems as examples is a great idea. I think that prescribing in the
Common Lisp spec how specific operating systems are to be treated is
possibly a good idea, but has some potential problems -- it makes the
Common Lisp spec dependent on specific operating systems that might
change out from under it; it might overspecify something that should
have been left to the discretion of implementors, in overreaction to the
present situation; it might encourage users to write nonportable
programs by paying attention only to the part of the spec for the
operating system they happened to develop on, ignoring the more general
portability concerns. These problems are not fatal if handled right.
I'm certain that handling each operating system in isolation, with no
coherency among them, is a recipe for disaster. It could increase
portability among multiple implementations on a single operating system,
but further damage portability between differing operating systems.
Unless you believe that no operating system but Unix will survive,
this would be doing no service to the users of Common Lisp.
I think this implies that you can't duck the PATHNAME-COMPONENT-CASE
issue so easily: you can't just say that each operating system can make
an individual choice.
Whether this will go over politically is difficult to judge. It didn't
work at all in 1983-4.
∂19-Sep-88 1715 CL-Cleanup-mailer Re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 17:15:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 19 SEP 88 16:51:07 PDT
Date: 19 Sep 88 16:51 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PEEK-CHAR-READ-CHAR-ECHO (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Thu, 23 Jun 88 15:53 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880919-165107-2710@Xerox>
I at first doubted your Current Practice until I tried it myself -- it certainly
did differ among the implementations I tried.
Since as written there are no operating system interactions, I think this is
reasonable to put in the standard. I can't think of any important performance
issues.
I think you have picked on the two reasonable interpretations. I think
FIRST-READ-CHAR is preferable from the point of view of many applications.
Suppose a special version of READ is implemented in terms of READ-CHAR, and
further that its written
(case (setq first (read-char))
(#\( ... read list ...)
(#\# ... read dispatching macro ...)
.... other special cases ...
(otherwise (unread-char first) (read-symbol)))
where read-symbol is written in terms of read-char. It would be unfortunate to
have the first character of each symbol echoed twice, as I think would be
required by PEEK-CHAR-READ-CHAR-ECHO:READ-CHAR.
∂19-Sep-88 1752 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from ti.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 17:51:52 PDT
Received: by ti.com id AA18628; Mon, 19 Sep 88 19:49:35 CDT
Received: from Kelvin by tilde id AA15142; Mon, 19 Sep 88 19:39:40 CDT
Message-Id: <2799708057-5084423@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 19 Sep 88 19:40:57 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PACKAGE-CLUTTER
In-Reply-To: Msg of Sat, 17 Sep 88 02:02:12 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
> Back
> when we all agreed that LISP should export only the symbols mentioned in
> CLtL (or the standard that replaces it), I thought that we also agreed that
> USER was the place where an implementation was allowed to provide its
> default environment. This means CLtL symbols plus whatever other stuff an
> implementation wants to define as extensions: debugging functions, graphics
> stuff, or whatever.
I thought the idea was that the USER package would use the
implementation-dependent package(s), not that the implementation-dependent
features would reside in the USER package.
∂19-Sep-88 1808 CL-Cleanup-mailer ARGUMENTS-UNDERSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:08:27 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05432; Mon, 19 Sep 88 18:06:59 PDT
Date: Mon, 19 Sep 88 18:06:59 PDT
Message-Id: <8809200106.AA05432@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: ARGUMENTS-UNDERSPECIFIED
From: DECWRL::MAILER-DAEMON "Mail Delivery Subsystem 19-Sep-88 0713 PDT" 19-SEP-1988 10:13:04.80
To: 37.975::chapman
CC:
Subj: Returned mail: Host unknown
----- Transcript of session follows -----
mail11: no host entry for sail-stanford-edu
550 cl-cleanup@sail-stanford-edu... Host unknown
----- Unsent message follows -----
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03664; Mon, 19 Sep 88 07:13:18 PDT
Message-Id: <8809191413.AA03664@decwrl.dec.com>
From: chapman@37.975.enet
Date: 19 Sep 88 10:11
To: cl-cleanup@sail-stanford-edu
Subject: ARGUMENTS-UNDERSPECIFIED
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
19-Sept-88, Version 3 by Chapman
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
PARSE-INTEGER start,end non-negative integers
PARSE-INTEGER start,end non-negative integers
SET-SYNTAX-FROM-CHAR to-char,from-char
characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may detect an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. PARSE-INTEGER may
detect
an error if the START or END arguments are not in the range of the "string"
argument.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
KMP believes the END argument to PARSE-INTEGER should be permitted to be
NIL, meaning use the rest of the string. This is most convenient from
an implementation point of view because one can write
&KEY (START 0) (END NIL)
If you say the argument must be an integer, you must write:
&KEY (START 0) (END NIL END-P)
and complain if END is NIL while END-P is T (which seems gratuitous
error checking since the functionality would be useful) or else you must
do
&KEY (START 0) (END (LENGTH STRING))
which is also gratuitous since the function will not be certain that the
value of END is correct and will have to do (LENGTH STRING) yet again in
order to validate the value of END.
KMP believe an analogous criterion should be applied to END arguments
across the board. and is writing this up
as a separate cleanup item.
Van Roggen concurs.
========================================================================
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03720; Mon, 19 Sep 88 07:13:18 PDT
∂19-Sep-88 1810 CL-Cleanup-mailer RETURN-VALUES-UNSPECIFIED
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 18:10:52 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA05517; Mon, 19 Sep 88 18:09:30 PDT
Date: Mon, 19 Sep 88 18:09:30 PDT
Message-Id: <8809200109.AA05517@decwrl.dec.com>
From: chapman%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: RETURN-VALUES-UNSPECIFIED
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the execution
of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from
these constructs.
Current Practice:
Adoption Cost:
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
Aesthetics:
None.
Discussion:
Masinter believes that it is marginally more useful to say that
INSPECT returns the item
inspected. Some interactive inspectors might allow you to return a new value as
the value of INSPECT, e.g., (SETQ X (INSPECT X)).
GLS disagrees. If one regards INSPECT as a tool in the interactive
interface, it can be a real nuisance to inspect some huge data structure
and then when you finish it insists on printing 300 lines of gobbledygook
at you.
PROVIDE and REQUIRE are not likely to appear except in the "top level" of files.
Van Roggen thinks that leaving the values of the debugging and module constructs open
to implementation specification is best for allowing experimentation
and growth.
========================================================================
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA03740; Mon, 19 Sep 88 07:13:32 PDT
∂19-Sep-88 2014 CL-Cleanup-mailer Issue: HASH-TABLE-ACCESS (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 20:14:34 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03947g; Mon, 19 Sep 88 19:12:54 PST
Received: by bhopal id AA16279g; Mon, 19 Sep 88 20:12:22 PDT
Date: Mon, 19 Sep 88 20:12:22 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200312.AA16279@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88 12:30:52 PDT <8809131930.AA14068@decwrl.dec.com>
Subject: Issue: HASH-TABLE-ACCESS (version 1)
re: Proposal: (HASH-TABLE-ACCESS:PROVIDE)
Add the following functions to the language:
HASH-TABLE-REHASH-SIZE hash-table
Returns the current rehash size of a hash table.
HASH-TABLE-REHASH-THRESHOLD hash-table
Returns the current rehash threshold of a hash table.
HASH-TABLE-SIZE hash-table
Returns the current size of a hash table.
HASH-TABLE-TEST hash-table
Returns the test used for comparing keys in the hash table.
By default the value will be either EQL or #'EQL.
Sigh, this issue is one of the very clear "Clarifications" that Guy
Steele issued on 6-Dec-1985, and which have not hitherto been turned
into format "Cleanup" proposals.
For the "Current Practice" section, you can mention that ever since the
2.0 release Lucid has provided all four accessors, as well as setf methods
for HASH-TABLE-REHASH-THRESHOLD and HASH-TABLE-REHASH-SIZE. [However,
they have not been in Lucid's documentation until the 3.0 release].
Could you be convinced to ask the for two setf "methods" too?
One other request: the return value of HASH-TABLE-TEST should
be among the values of 'EQ, 'EQL, or 'EQUAL -- not among #'EQ,
#'EQL, or #'EQUAL. I'd actually prefer to see MAKE-HASH-TABLE
restricted to 'EQ, 'EQL, or 'EQUAL since this argument is not
used for it's functional value so much as merely a way to signify
one choice out of three possible. But this is probably too much
backwards incompatibility for too little return; at least the
accessor function doesn't have to perpetuate the myth that
any old function of two arguments is acceptable as a hash-table
:test argument.
-- JonL --
∂19-Sep-88 2036 CL-Cleanup-mailer Issue: TAILP-NIL (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 19 Sep 88 20:36:23 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03955g; Mon, 19 Sep 88 19:34:42 PST
Received: by bhopal id AA16338g; Mon, 19 Sep 88 20:34:10 PDT
Date: Mon, 19 Sep 88 20:34:10 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200334.AA16338@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Tue, 13 Sep 88 12:37:02 PDT <8809131937.AA14339@decwrl.dec.com>
Subject: Issue: TAILP-NIL (version 1)
TAILP-NIL:NIL is what Lucid Common Lisp supports, albeit for the
"wrong" reason. Since this issue has been around for nearly three
years (GLS's "Clarifications"), and since there has been no public
complaints about the many implementations that do it this way, then
codifying this seems right.
I wouldn't mind a line in your proposal that requires TAILP to signal
an error if the 'sublis' argument is any non-null atom.
-- JonL --
∂19-Sep-88 2222 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 19 Sep 88 22:22:11 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 20 Sep 88 01:20:11 EDT
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Your message of Mon, 19 Sep 88 19:40:57 -0500.
<2799708057-5084423@Kelvin>
Date: Tue, 20 Sep 88 01:20:02 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I thought the idea was that the USER package would use the
implementation-dependent package(s), not that the implementation-dependent
features would reside in the USER package.
Sure. Careless wording on my part. I don't see what difference this
makes, however: the point is that there can be symbols accessible in USER
that are not among those named in CLtL. One would hope that each
implementation would document all these sysmbols, but I don't think the
standard has any business requiring this.
-- Scott
∂19-Sep-88 2342 CL-Cleanup-mailer Re: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Sep 88 23:42:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 19 SEP 88 23:40:35 PDT
Date: 19 Sep 88 23:40 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 12 Sep 88 18:05 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880919-234035-3227@Xerox>
As for current practice:
Envos Medley (I guess I should say that instead of Xerox Common Lisp?)
implements
(room &optional types page-limit in-use-limit)
I suppose as an "extension" to CLtL. Types is a list of type names to report
storage usage for (defaults to all), and page-limit and in-use-limit also
constrain the types reported (since the allocation scheme allow distinguishing
storage use by type).
Imagine two other proposals:
ROOM-DEFAULT-ARGUMENT:MAKE-EXPLICITLY-VAGUE (what ROOM does and what its
arguments beyond (ROOM) do are non-portable),
ROOM-DEFAULT-ARGUMENT:REMOVE (remove ROOM from the standard)
ROOM-DEFAULT-ARGUMENT:MAKE-KEYWORD (implementations can add arbitrary keywords
to ROOM, that can be interpreted however they want, except that they have to
(ROOM &ALLOW-OTHER-KEYS)).
My vote: I'd go for MAKE-EXPLICITLY-VAGUE first and ALLOW-OTHER-KEYS second
over the other two.
∂20-Sep-88 0022 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 00:21:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04084g; Mon, 19 Sep 88 23:20:21 PST
Received: by bhopal id AA16980g; Tue, 20 Sep 88 00:19:47 PDT
Date: Tue, 20 Sep 88 00:19:47 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809200719.AA16980@bhopal>
To: vanroggen%aitg.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 14 Sep 88 07:46:51 PDT <8809141446.AA04055@decwrl.dec.com>
Subject: Issue: PACKAGE-CLUTTER
re: I think this issue also needs to address the default value for :USEd
packages. (Or else the name should be changed to something more
specific like LISP-PACKAGE-CONTENTS.)
Agreed. Either change the issue name, or add an amendment addressing
the default value for the :use argument to make-package.
re: If we allow the default value for :USE to be implementation dependent,
I think users would be most happy. If someone really wants just Common
Lisp, they would be able to say :USE '("LISP"). Otherwise they would
be able to get the same environment that the USER package has, since
implementations would have the flexibility to make them the same and
as rich as they would like to make them.
From the vendors point of view, I think this is an overriding issue.
Nearly every vendor sells to a customer base in which users write code
*primarily* for that vendor's Lisp. Only a *very few* research
establishments are propogating ideas in the form of portable code;
and a couple of tools builders are supplying their product on many
vendor's platforms. Since there is only one option available for the
:use default, Lucid has already decided to give the very tiny bias
towards the overwhelmingly larger customer base. The advantages to
this larger "base" are:
(1) Greater conformance of the vendor's documentation with what is
actually available in the default package -- USER -- and in a
new package made with the default options.
(2) No need to insist that the vendor document all his extensions
as, say, ACME-COMMON-LISP:WONDERFUL, but his manual can simply
say WONDERFUL without "qualification".
(3) A few keystrokes less when typing MAKE-PACKAGE (or IN-PACKAGE).
Now, the downside for those actually writing portable code seems to be
exactly null. At worst it would merely mean that they would have to add
an explicit :use argument to each call to MAKE-PACKAGE (or to IN-PACKAGE).
However, as a practical matter, it turns out they have done this already.
I remember Dave Plummer of Symbolics mentioning two years ago that even
when not writing portable code, he never allowed the :use argument to be
defaulted. [Why? I'm not sure, but having survived several internal
changes myself, I suspect it was to insulate onself from the shifting
winds of developement cycles.]
The issue is not portability, but rather deciding which part of the user
community has to type those extra keystrokes.
re: I think this is what resulted from those CL discussions a few years ago.
I'd guess that this is also what several implementations do. Anyone
care to comment?
I think so too. [In fact, Lucid changed it's layout about a year ago to
conform to what you describe]. In those discussions of 1986, I remember
three main highlights:
(1) The LISP package should not contain any symbols other than the 775
found in CLtL (which of course must be external); several mail
iterations were required to get the several vendors to agree on
the specific list of 775. Most people agreed on this issue, but
there may have been one or two holdouts.
(2) Vendor-specific extensions should not be put into *any* of the
CLtL specified packages -- not even SYSTEM -- since by definition
they will not be portable, and since a coincidence of names in the
"extensions" package between two different vendors would probably
not imply the same functionality.
(3) The favored suggestion (which may not have had consensus) for the
vendor-specific extensions was that they should be placed into a
package named like ACME-COMMON-LISP for the "Acme" company. Paul
the greek even volunteered to maintain a registry of names for
such packages (but alas ...).
-- JonL --
∂20-Sep-88 0028 CL-Cleanup-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 00:28:02 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 20 SEP 88 00:13:04 PDT
Date: 20 Sep 88 00:13 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Sat, 12 Mar 88 20:02 EST
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-001304-3264@Xerox>
The last message I can find on this issue is your message of last March. I've
misplaced Mathis message with the last minutes meetings; while I did note most
of the issues that were passed and discussed.
This one I recall was held up pending the function-spec proposal. However, I'm
suprised we don't have a writeup past Version 3, given what I think were
reasonable comments from Kent.
Did I misplace some mail?
To recall:
Date: Sat, 12 Mar 88 20:02 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-FUNCTION-VS-MACRO (version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880214-134110-1441@Xerox>
Message-ID: <880312200240.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
[X3J13 removed.]
I support many ideas of this proposal, but I have two gripes which make me
have to oppose it:
* I can't deal with the idea of generalizing SYMBOL-FUNCTION. I would like
to see FDEFINITION introduced and SYMBOL-FUNCTION left alone.
* I'm also a little leary about TRACE being extended this way because
(TRACE (a list)) might later want to be interpreted as options rather
than as a function spec and I'd rather not have to risk heuristic resolution.
I would rather someone right now introduce a generalized syntax for TRACE
with syntactic space for trace options, such as
(TRACE (fn . options) (fn . options) (fn . options))
and then allow the generalized (non-symbol) fn to only occur within that
syntax so that no ambiguity results.
∂20-Sep-88 0039 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 00:39:01 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 20 SEP 88 00:37:38 PDT
Date: 20 Sep 88 00:37 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-CLUTTER
In-reply-to: Jon L White <jonl@lucid.com>'s message of Tue, 20 Sep 88 00:19:47
PDT
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880920-003738-3287@Xerox>
When you're about to release Lucid Common Lisp version 17, you'll be glad that
we made the default for :USE be LISP so that you could support users who want to
:USE '("LUCID-3-0") ?
What's today a vendor-to-vendor issue is as likely to become a
version-to-version issue for you, no?
∂20-Sep-88 0040 CL-Cleanup-mailer Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 00:40:19 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 00:38:35 PDT
Date: 20 Sep 88 00:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-FUNCTION-VS-MACRO (version 3)
In-reply-to: masinter.pa's message of 20 Sep 88 00:13 PDT
To: masinter.pa@Xerox.COM
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-003835-3289@Xerox>
"meeting's minutes", not "minutes meetings". I guess I should go home....
∂20-Sep-88 0127 CL-Cleanup-mailer Re: Issue: STACK-LET (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 01:27:42 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 01:26:21 PDT
Date: 20 Sep 88 01:26 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STACK-LET (Version 1)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880920-012621-3322@Xerox>
This issue (discussed on Common-lisp@sail.stanford.edu instead of cl-cleanup, by
mistake?) has had no discussion since July 1. I don't think the issue is
STACK-LET but some kind of DYNAMIC-EXTENT-VALUES if we don't want to prejudice
the issue to a specific proposal.
This should certainly remain an active issue at some level, but I think the
current proposal is not adequate.
Is it useful to bring it up to X3J13 in its current form?
∂20-Sep-88 0129 CL-Cleanup-mailer Issue: STANDARD-CLASS-OVERHEAD
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 01:28:59 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 01:27:39 PDT
Date: 20 Sep 88 01:27 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STANDARD-CLASS-OVERHEAD
In-reply-to: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>'s message of Wed, 31
Aug 88 15:28:13 EDT
To: Michael J. Beckerle <BECKERLE@XX.LCS.MIT.EDU>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880920-012739-3323@Xerox>
Are you satisfied with Gregor's response on this issue, or do you want to pursue
this as a cleanup item?
∂20-Sep-88 0218 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 02:18:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 02:16:33 PDT
Date: 20 Sep 88 02:16 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-CAPABILITIES
In-reply-to: vanroggen%aitg.DEC@decwrl.dec.com's message of Wed, 14 Sep 88
07:29:16 PDT
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880920-021633-3385@Xerox>
Yes, its not so much the necessity of STREAM-SAME-xxx-P as it is the likelihood
of them being correctly implementable for any of the likely operating systems,
especially in the presence of network file systems, pipes, streams, indirects,
redirects, etc.
I think adding something that cannot be correctly implemented will lead to more
rather than less portable code.
I think INTERACTIVE-STREAM-P is implementable, however, if only because it is
reasonable to be conservative.
It is important to answer the questions about CL-constructed streams lest we
differ: what about MAKE-ECHO-STREAM MAKE-BROADCAST-STREAM MAKE-TWO-WAY-STREAM
with regard to their transformation of INTERACTIVE-STREAM-Ps to non-interactive
ones?
The STREAM-SOURCE-ID-LIST proposal has some merits, but reminds me of Godel
numbering schemes.
Dans reasoning "Pierson supports STREAM-CAPABILITIES:NEW-PREDICATES because he
is
concerned that it may be hard for implementations to provide the list
functions efficiently because the natural token type for multiple,
disjoint types of streams may be integers. The implementation would
have to coerce these integers in to some other type of token that
would be guaranteed unique across all possible stream types."
doesn't follow from the proposal, does it? Some streams could have integers as
tokens (are you thinking of their inode number or something?), and others not.
∂20-Sep-88 0927 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88 09:27:30 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA03013; Tue, 20 Sep 88 10:26:06 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA00355; Tue, 20 Sep 88 10:26:01 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809201626.AA00355@defun.utah.edu>
Date: Tue, 20 Sep 88 10:25:59 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@nss.cs.ucl.ac.uk>
Cc: sandra <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu,
kmp@scrc-stony-brook.arpa, cl-cleanup@sail.stanford.edu
In-Reply-To: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Tue, 20 Sep 88 16:19:42 BST
> Date: Tue, 20 Sep 88 16:19:42 BST
> From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
>
> I am less hapy with the exception that allows the interpreter to
> multiply evaluate the expression to produce a new value each time.
This argument would bear a lot more weight with me if you could
suggest some implementation technique that guarantees only a single
evaluation in the interpreter that doesn't require the intepreter to
perform a preprocessing code walk, and still provides reasonable
semantics. I thought about this for a long time and was unable to
come up with any other way to implement the semantics in KMP's
proposal. I think it is unreasonable to force implementations that
don't use a preprocessor to rewrite their interpreter just to support
this new special form.
> While the exception is consistent with the rules for macros, I
> do not think the two cases are really analogous. LOAD-TIME-VALUE
> results in an object, so it matters if the object is a different
> one each time.
Macros can construct and return (quoted) objects as well. I don't
think that allowing multiple evaluations of LOAD-TIME-VALUE is really
all that much more confusing than allowing macros to be expanded more
than once.
> I suspect it will be a pain to write code that can take advantage
> of the COMPILE-FILE guarantee but nonetheless still work if the
> form is multiply evaluated.
I agree, this is something that is likely to confuse users, but it's the
best I could come up with. If you can suggest some other compromise
that will accomodate both destructive operations and those implementations
that don't use a preprocessor in the interpreter, by all means do so.
> > If a LOAD-TIME-VALUE expression appears within a function compiled
> > with COMPILE, the compiler may either evaluate the <form> or use
> > a previously cached value.
>
> I'm not sure what this means. Does it mean that different code
> compiled at different times can nonetheless end up using the same
> value? (I hope not....)
No, what it means is that if you compile an interpreted function that
has already gone through some preprocessing to evaluate a LOAD-TIME-VALUE
expression in the body, the compiler can reuse that value instead of
having to reconstruct the source code and evaluate it again. The
wording should probably be more specific about this.
-Sandra
-------
∂20-Sep-88 1005 CL-Cleanup-mailer Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:05:40 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04417g; Tue, 20 Sep 88 09:03:57 PST
Received: by bhopal id AA18360g; Tue, 20 Sep 88 10:03:23 PDT
Date: Tue, 20 Sep 88 10:03:23 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809201703.AA18360@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 14 Sep 88 12:42 EDT <880914124243.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: RANGE-OF-START-AND-END-PARAMETERS (Version 1)
Lucid Common Lisp implements the described behaviour; I support
this clarification.
-- JonL --
∂20-Sep-88 1019 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:19:48 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04438g; Tue, 20 Sep 88 09:18:09 PST
Received: by bhopal id AA18425g; Tue, 20 Sep 88 10:17:37 PDT
Date: Tue, 20 Sep 88 10:17:37 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809201717.AA18425@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 14 Sep 88 12:07 PDT <880914-120836-2043@Xerox>
Subject: Issue: DEFPACKAGE (version 2)
re: There's been no discussion on this proposal since 8 Jun, when it was
distributed in draft form to X3J13. I am taking this to mean that people
are not unhappy with the version of 23-Mar-88 -- at least not unhappy
enough to complain or suggest improvements.
Not so. When you distributed the draft in June, I reminded you then that
I had serious objections to one part of this proposal, and that moon
hadn't addressed them satisfactorily at that time.
A series of messages took place on "Cleanup" after I sent out the one
reproduced below. Moon acceeded to the first point one, but never came
to any resolution about point two -- to flush two redundant and *dangerous*
options :IMPORT and :SHADOWING-IMPORT. There still has not been a revised
version of the proposal circulated; presumably the revision should wait
until the second point is resolved.
-- JonL --
-------------------------------------------------------------------------------
Date: Tue, 17 May 88 02:05:55 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 23 Mar 88 14:49 EST ...
Subject: Issue: DEFPACKAGE (version 2)
There is one very dangerous loophole in this proposal, which could be
trivially plugged up. The issue is whether symbols are a critical
arugment to any of the options, or whether "names" would be satisfactory.
What would you say to the following alterations:
(1) Change most uses of the meta-variable {symbol} to {name}, with
an explicit statement that such a {name} must be either a string,
or a symbol. Thus the description of :IMPORT-FROM would go from
(:IMPORT-FROM {(package-name {symbol}*)}*)
to
(:IMPORT-FROM {(package-name {name}*)}*)
or maybe even
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
Change also the phrase "Note that only the name of each argument symbol
is used." to something like "Note that only the name of each argument
is used; if a symbol is passed, its symbol-name is used".
(2) Flush the two options that require symbols, as opposed to names --
namely :IMPORT and :SHADOWING-IMPORT. Note that these are the only
two that don't have the phrase "Note that only the name of each
argument symbol is used." in their description. These two options
are superfluous since their functionality is completely covered by
:IMPORT-FROM and :SHADOWING-IMPORT-FROM.
The :IMPORT option as currently specified makes it all too easy to violate
reasonable package modularity rules -- e.g. (:IMPORT foo::bar) -- without
considering the warning given on CLtL p175 (top of page) "... since
accessing an internal symbol of some other package is usually a mistake".
Much worse, I've seen even very experienced hackers (more than 10 years
experience) fall into the trap of thinking that FOO::BAR means "access
the internal symbol BAR in the FOO package", or "access the symbol BAR
present in the FOO package, regardless of whether it is external or not".
The disaster that occurs once in a long while is that merely reading in
FOO::BAR creates some imposter symbol in the BAR package that shouldn't
be there at all; but the poor loser who does this doesn't find that out
until a much later time, when a USE-PACKAGE or EXPORT is done. And of
course by the time he finds it out, there is little hope of ferreting
out all the structures already read-in that point to the bogon symbol.
It may be too much to ask that the :IMPORT-FROM option signal an error
if no symbol of the requested name is available in the specified package.
This would (desirably, I think) differ from the reader's action when
parsing a double-colon notation. But at the very least, why add the
:IMPORT and :SHADOWING-IMPORT options that *require* symbols as opposed to
names? Why, when there are perfectly good alternatives that don't have
the modularity-violating implications described above?
If these two alterations are made, then a DEFPACKAGE can be written with
all data specified as strings; and in the cases when symbols are actually
are supplied, then the compiler can convert them to strings as they are
put out into the fasl file. (Essentially the same compiler conversion
takes place now in Symbolics treatment of SHADOW, and in Lucid's 3.0
release version of SHADOW).
-- JonL --
-------------------------------------------------------------------------------
∂20-Sep-88 1024 CL-Cleanup-mailer Re: Issue: STREAM-CAPABILITIES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:24:19 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462457; Tue 20-Sep-88 13:22:24 EDT
Date: Tue, 20 Sep 88 13:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: STREAM-CAPABILITIES
To: masinter.pa@Xerox.COM
cc: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <880920-021633-3385@Xerox>
Message-ID: <19880920172214.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 20 Sep 88 02:16 PDT
From: masinter.pa@Xerox.COM
....
I think INTERACTIVE-STREAM-P is implementable, however, if only because it is
reasonable to be conservative.
It is important to answer the questions about CL-constructed streams lest we
differ: what about MAKE-ECHO-STREAM MAKE-BROADCAST-STREAM MAKE-TWO-WAY-STREAM
with regard to their transformation of INTERACTIVE-STREAM-Ps to non-interactive
ones?
I believe that interactivity is a property of input streams: it means
that input from the stream is coming from an intelligent agent which
bases his/her/its input on observations of the state of the system,
which might include output to various streams. A non-interactive
stream, in contrast, is one whose input comes from some kind of "canned"
source. There might be gray areas where an implementor has to use
his judgement, but that's not a fatal flaw.
One could argue that an output stream can be interactive, which means
that an intelligent agent is more likely to look at what is written to
that stream (e.g. it's displayed directly in a window, rather than being
sent to a file that would have to be examined; but what if the window is
covered over?). I don't think this is a useful distinction.
If we agree that interactivity is a property of input streams, then
the answers follow: MAKE-ECHO-STREAM and MAKE-TWO-WAY-STREAM get the
interactivity from their input-stream. Since MAKE-BROADCAST-STREAM
makes output streams, INTERACTIVE-STREAM-P is either invalid or
always returns NIL, whichever it's defined to be for output streams.
MAKE-CONCATENATED-STREAM is wierd, but I guess the only sensible
choice is that it gets its interactivity from the currently active
input stream, or if all of them have been used up, it's not interactive.
∂20-Sep-88 1038 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:38:14 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462476; Tue 20-Sep-88 13:36:20 EDT
Date: Tue, 20 Sep 88 13:36 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, CL-Cleanup@Sail.stanford.edu
In-Reply-To: <8809201717.AA18425@bhopal>
Message-ID: <19880920173616.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I've re-read the mail from May and I simply don't buy your arguments.
I don't see any need to change anything in the version 2 proposal.
If you want to write a competitive proposal, that's fine; not only
will I not complain, I'll be enthusiastic that I'm not the only one
working on the issue. However, you'll have to be clearer in your
arguments than in May to convince me that your proposal is
better. I think all your arguments are variations on: using symbols
with package prefixes in a DEFPACKAGE form is more dangerous than
using symbols with package prefixes in other forms. My position
is that DEFPACKAGE is no different from anything else in this respect.
∂20-Sep-88 1044 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:42:19 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05475; 20 Sep 88 15:44 BST
Date: Tue, 20 Sep 88 16:19:42 BST
Message-Id: <1342.8809201519@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: sandra <@cs.utah.edu:sandra@defun>, cl-compiler@sail.stanford.edu,
kmp@scrc-stony-brook.arpa
In-Reply-To: sandra's message of Mon, 19 Sep 88 14:06:15 MDT
Cc: cl-cleanup@sail.stanford.edu
I am more or less in favor of the proposal. LOAD-TIME-VALUE is
a much better name than LOAD-TIME-CONSTANT if we are going to
allow the value to be a reliably modifiable object. And I
agree with KMP's arguments that it should be modifiable.
I am less hapy with the exception that allows the interpreter to
multiply evaluate the expression to produce a new value each time.
While the exception is consistent with the rules for macros, I
do not think the two cases are really analogous. LOAD-TIME-VALUE
results in an object, so it matters if the object is a different
one each time.
> LOAD-TIME-VALUE is, in effect, a promise by the user that multiple
> evaluations of <form> will return values that are semantically
> equivalent (although not necessary EQ).
What this means, in part, is that the programmer can't mean EQ by
"semantically equivalent" in interpreted code but can in compiled.
I suspect it will be a pain to write code that can take advantage
of the COMPILE-FILE guarantee but nonetheless still work if the
form is multiply evaluated.
> If a LOAD-TIME-VALUE expression is seen by COMPILE-FILE, [...] It
> is guaranteed that the evaluation of <form> will take place only once
> when the file is loaded
To me, the value of this guarantee is much less when it does not
apply when interpreting.
> If a LOAD-TIME-VALUE expression appears within a function compiled
> with COMPILE, the compiler may either evaluate the <form> or use
> a previously cached value.
I'm not sure what this means. Does it mean that different code
compiled at different times can nonetheless end up using the same
value? (I hope not....)
-- Jeff
∂20-Sep-88 1047 CL-Cleanup-mailer Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 10:46:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04482g; Tue, 20 Sep 88 09:45:17 PST
Received: by bhopal id AA18564g; Tue, 20 Sep 88 10:44:45 PDT
Date: Tue, 20 Sep 88 10:44:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809201744.AA18564@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 14 Sep 88 16:27 EDT <19880914202753.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
This proposal accurately reflects the state of Lucid Common Lisp,
Release 3.0; previous releases implemented CLtL.
Incidentally, I know we thrashed this issue out on Common-Lisp@SU-AI
some months ago; and I remember initiating the discussion with a query
msg to find out how other people felt about the issue. However your
"References" field shows only the very cryptic:
<8807200836.AA02976@bhopal.lucid.com>,
<19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
<870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I've noticed that this kind of encryption always occurs whe Symbolics
folks try to reference prior mail; it must be some kind of "feature"
in the Symbolics mailer?
Could you possibly restore something more like the original dateline;
on these references, with at least (1) which mailing list to which
the msg was sent, (2) the "From" name, and (3) a readily understandable
date format [e.g. Wed, 14 Sep 88 16:27 EDT]. Thanks.
-- JonL --
∂20-Sep-88 1151 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 11:51:13 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 11:35:34 PDT
Date: 20 Sep 88 11:35 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: dick@wheaties.ai.mit.edu (Richard C. Waters)'s message of Tue, 5
Jul 88 11:55:44 EDT
To: dick@wheaties.ai.mit.edu (Richard C. Waters)
cc: gls@think.com, masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
Message-ID: <880920-113534-4339@Xerox>
After the discussion on this issue in late June and early July, it seemed like
it was time for us to get a revised proposal, at least mentioning the things
that came up in discussion.
Is there any chance of getting something like that from you this week? Sorry for
the late notice, but we're trying to prepare for the October meeting of X3J13.
∂20-Sep-88 1201 CL-Cleanup-mailer (only slightly about) Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 12:01:48 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 462562; 20 Sep 88 14:59:58 EDT
Date: Tue, 20 Sep 88 14:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: (only slightly about) Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
To: jonl@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@sail.stanford.edu
In-Reply-To: <8809201744.AA18564@bhopal>
Message-ID: <880920145942.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 20 Sep 88 10:44:45 PDT
From: Jon L White <jonl@lucid.com>
... I've noticed that this kind of encryption always occurs whe Symbolics
folks try to reference prior mail; it must be some kind of "feature"
in the Symbolics mailer? ...
We didn't do the encrypting. Our mailer tries to refer to messages by
their unique Message-ID designation where one exists. This allows us,
among other things, to sort conversations by message references or to
select a particular conversation in isolation so that we can see whole
conversations contiguously rather than mixed up with unrelated messages.
The Message-ID was generated at your end.
When no unique Message-ID is available, our mail sending program uses
the less reliable and more verbose "The message of <when> at <where>"
format to refer to the reply.
... Could you possibly restore something more like the original dateline;
on these references, with at least (1) which mailing list to which
the msg was sent, (2) the "From" name, and (3) a readily understandable
date format [e.g. Wed, 14 Sep 88 16:27 EDT]. Thanks. ...
Some mailers use an organized theory of constructing message id's in an attempt
to make them not clash. There is no general theory for unpacking such message
ids, but here are my guesses:
<8807200836.AA02976@bhopal.lucid.com>
is probably "The message of 20-Jul-88 8:36am PDT from someone@Lucid" (JonL?)
<19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
is probably "The message of 19-Jul-88 3:22pm EDT from Moon@STONY-BROOK.SCRC.Symbolics.COM"
<19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
is probably "The message of 19-Jul-88 9:38pm from Greenwald@STONY-BROOK.SCRC.Symbolics.COM"
<870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
is probably "The message of 2-Apr-87 5:09pm EDT from Moon@STONY-BROOK.SCRC.Symbolics.COM"
∂20-Sep-88 1210 CL-Cleanup-mailer message references
Received: from ALLEGHENY.SCRC.Symbolics.COM ([128.81.41.45]) by SAIL.Stanford.EDU with TCP; 20 Sep 88 12:09:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by ALLEGHENY.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 107506; Tue 20-Sep-88 15:08:11 EDT
Date: Tue, 20 Sep 88 15:08 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: message references
To: Jon L White <jonl@lucid.com>
cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: <8809201744.AA18564@bhopal>
Message-ID: <19880920190805.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 20 Sep 88 10:44:45 PDT
From: Jon L White <jonl@lucid.com>
Incidentally, I know we thrashed this issue out on Common-Lisp@SU-AI
some months ago; and I remember initiating the discussion with a query
msg to find out how other people felt about the issue. However your
"References" field shows only the very cryptic:
<8807200836.AA02976@bhopal.lucid.com>,
<19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
<870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I've noticed that this kind of encryption always occurs whe Symbolics
folks try to reference prior mail; it must be some kind of "feature"
in the Symbolics mailer?
Those message-IDs follow the Internet standard for mail and were
generated by the original sender, not by my reply. There is no
encryption going on. There is nothing Symbolics-specific going on. I
have no control over these IDs, except possibly for the ones on the
messages that I sent originally.
Could you possibly restore something more like the original dateline;
on these references, with at least (1) which mailing list to which
the msg was sent, (2) the "From" name, and (3) a readily understandable
date format [e.g. Wed, 14 Sep 88 16:27 EDT]. Thanks.
If you can't retrieve messages from mail archives by message-ID, you can
ask me to retrieve them for you. It may take me several weeks to get
around to doing it, though, if I don't already have the messages locally.
You use Unix, don't you? I'm surprised that it doesn't implement the
Internet standard for mail.
∂20-Sep-88 1258 CL-Cleanup-mailer clcleanup mail archives
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 12:58:23 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 12:49:54 PDT
Date: 20 Sep 88 12:49 PDT
From: masinter.pa@Xerox.COM
Subject: clcleanup mail archives
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 20 Sep 88 15:08 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <880920-124954-4553@Xerox>
I can now make my archives of the mail on any issue available from anonymous
login....
Look for
clcleanup/mail/issuename.mail
where issuename is the name of the issue, e.g.,
clcleanup/mail/with-open-string-append-style.mail
Caveats: the files use CR for the end-of-line convention, even though arisia is
a unix host. The messages are not necessarily sorted in order. There's an odd
chance that there's some personal mail mixed in with the public, so please be
careful (don't forward, etc.)
I won't keep the files up to date but will update them on request.
∂20-Sep-88 1649 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 16:49:07 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462806; Tue 20-Sep-88 19:46:13 EDT
Date: Tue, 20 Sep 88 19:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: <8809192006.AA00963@defun.utah.edu>
Message-ID: <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I am highly opposed to your whole approach here. I know KMP doesn't
agree with me, so this is just my personal opinion. Let me see if I can
explain without getting long-winded. I've deleted about half of what I
started to say, which was really irrelevant.
You could simply have made the mechanism underlying #, available.
Instead, you chose to design a new mechanism that works a different way.
This requires either having two ways to do load-time evaluation, or
incompatibly changing #, to work the new way. You chose the latter
course. This makes #, incompatible both with #. and with its previous
definition.
The new mechanism has all sorts of problems with multiple evaluation
that #, did not have. The semantics of #, were very clear, if somewhat
off the wall.
The new mechanism tempts you to introduce a new concept of non-read-only
constants, since now you have a place to put options. This further
complicates the multiple evaluation issue by raising the issue of
side-effects and object sharing. It also requires a complicated rule
about when the compiler can collapse apparently equal constants. It's
also harder to implement than you think; any implementation that
formerly treated all constants as read-only now needs a way to label
each constant as read-only or writable.
The rationale claims that replacing #, with LOAD-TIME-VALUE simplifies
the description of Common Lisp, but this is clearly false. Even a
rigorous description of #, would be much less verbose than this proposal.
So what makes #, simpler than LOAD-TIME-VALUE? Since #, can only be used
inside quoted constants, we don't need any new rules about how the result
can be used. Since #, is a feature of LOAD rather than of EVAL, we don't
need any new rules about what happens if you evaluate it twice. Since
#, is a feature of LOAD rather than of EVAL, there is no issue of
semantic incompatibility between the compiler and the interpreter.
How to make the mechanism underlying #, available? This would be a
function that receives a form and returns an object (I'd use the term
"magic cookie" if I didn't hate it) which can be placed inside a quoted
constant; by the time the program is loaded, that position in the quoted
constant will contain the result of evaluating the form in the null
lexical environment. It is only useful to call this function from
macros. This function needs a way to tell whether a COMPILE-FILE is in
progress or not (as does CLOS); I hope that the compiler committee is
going to propose that the environment argument to macros can be used for
this purpose. Symbolics Genera currently uses a special variable to
convey this information, which has all the bugs that dynamic scoping
always has.
∂20-Sep-88 1715 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 17:14:51 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04854g; Tue, 20 Sep 88 16:12:30 PST
Received: by blacksox id AA01124g; Tue, 20 Sep 88 17:10:12 pdt
Date: Tue, 20 Sep 88 17:10:12 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809210010.AA01124@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 19:46 EDT <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
I agree completely with Moon's criticism of this proposal. I would
prefer to remove #, and its functionality altogether from the
language. It just isn't that important. I have yet to see any use for
#, which could not have been achieved by other means.
∂20-Sep-88 1721 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 17:20:53 PDT
Received: by ti.com id AA27117; Tue, 20 Sep 88 19:17:59 CDT
Received: from dsg by tilde id AA10707; Tue, 20 Sep 88 19:13:49 CDT
Received: From Kelvin By dsg Via CHAOS-NET With CHAOS-MAIL; Tue, 20 Sep 88 19:15:00 CDT
Message-Id: <2799792286-10241446@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 20 Sep 88 19:04:46 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
In-Reply-To: Msg of Sun, 18 Sep 88 16:22 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
> (if (and (typep x 'fixnum) (typep y 'fixnum))
> (locally (declare (fixnum x y))
> ...algorithm using x and y...)
> ...similar algorithm using x and y...)
>
> Proposal (DECLARE-TYPE-FREE:ALLOW):
>
> Change the phrase "affects only variable bindings" to "concerns variable
> bindings." Clarify that this makes the above program a valid program
> and that this kind of declaration means the same thing as inserting
> THE in every reference to the variable and every setq of the variable.
The phrase "concerns variable bindings" still doesn't seem right. There
are really two distinct cases: a declaration associated with a binding
and a local declaration separate from the binding. The former differs
because it not only describes the type of values which the variable will
assume, but also permits using a specialized representation for the
variable's value cell.
Should add that if there is both a binding declaration and a local
declaration for the type of the same variable, then, within the scope of
the local declaration, it is an error for the variable to contain a value
which is not a member of the intersection of the two types. (This implies
that it would be desirable for the compiler to complain if the two types
are disjoint.)
> Rationale:
>
> There is no reason to forbid this usage, and people have often asked
> for it.
I don't feel good about this because I'm afraid it would encourage users
to make the incorrect assumption that a local declaration is just as good
as a binding declaration. There will also be some performance penalty in
the compiler for looking up type declarations on a local declaration stack
instead of just having it as part of the variable table entry.
> Cost to Implementors:
>
> None, it is valid to ignore type declarations.
But some implementations will have the (admittedly slight) cost of
removing or updating an error check. Besides, you really haven't done the
user any favor to allow him to declare types this way if the compiler is
just going to ignore it, so any implementor that uses type declarations
should feel obligated to support this fully if at all.
> Benefits:
>
> The above example will not have to be written in the following silly way,
> which only works if x and y are used read-only:
>
> (if (and (typep x 'fixnum) (typep y 'fixnum))
> (let ((x x) (y y))
> (declare (fixnum x y))
> ...algorithm using x and y...)
> ...similar algorithm using x and y...)
But there might actually be an advantage to writing it this way. If you
are compiling for a conventional machine and the declarations are because
you want the most efficient code generated, then it may be worthwhile to
move the value to a fixnum cell rather than to reference it from a cell
that can hold a tagged object. On a Lisp Machine where all cells are
tagged, the compiler can optimize out the binding.
∂20-Sep-88 1746 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 17:46:21 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462833; Tue 20-Sep-88 20:43:28 EDT
Date: Tue, 20 Sep 88 20:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: eb@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
cl-cleanup@sail.stanford.edu
In-Reply-To: <8809210010.AA01124@blacksox>
Message-ID: <880920204310.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 20 Sep 88 17:10:12 pdt
From: Eric Benson <eb@lucid.com>
... I would prefer to remove #, and its functionality altogether from
the language. It just isn't that important. I have yet to see any
use for #, which could not have been achieved by other means.
Sigh. I simply don't believe this claim. We had this whole discussion
on CL-Compiler because CL-Cleanup yielded up responsibility for it.
There were several people making the same claim as you who are now
sounding swayed by the discussion. If necessary, I will send you and the
others copies of the mail dealing with this topic so you can pick up
where that discussion left off without our needlessly duplicating the
work we've already been through on this.
∂20-Sep-88 1800 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:00:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462840; Tue 20-Sep-88 20:55:34 EDT
Date: Tue, 20 Sep 88 20:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799792286-10241446@Kelvin>
Message-ID: <19880921005536.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 20 Sep 88 19:04:46 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> (if (and (typep x 'fixnum) (typep y 'fixnum))
> (locally (declare (fixnum x y))
> ...algorithm using x and y...)
> ...similar algorithm using x and y...)
>
> Proposal (DECLARE-TYPE-FREE:ALLOW):
>
> Change the phrase "affects only variable bindings" to "concerns variable
> bindings." Clarify that this makes the above program a valid program
> and that this kind of declaration means the same thing as inserting
> THE in every reference to the variable and every setq of the variable.
The phrase "concerns variable bindings" still doesn't seem right.
You're right. I cribbed that phrase from the preceding page or two in CLtL,
but here I was making the mistake of talking about what CLtL should say
rather than about what Common Lisp should be. I also think the word
"binding" should never be used when discussing Lisp, since some people
think it relates to LET (i.e. refers to creating a new variable), some
people think it relates to SYMBOL-VALUE (i.e. refers to the value associated
with a special variable), and some people think it relates to EVAL (i.e.
refers to the value associated with any kind of variable). How about
"concerns the values that a variable may take on"? The point is that
it is an error for the value of the variable to be not a member of the
declared type, within the scope of the declaration; all else is editorial.
Should add that if there is both a binding declaration and a local
declaration for the type of the same variable, then, within the scope of
the local declaration, it is an error for the variable to contain a value
which is not a member of the intersection of the two types. (This implies
that it would be desirable for the compiler to complain if the two types
are disjoint.)
True. Does the proposal really need to say this? It's a pretty obvious
consequence.
There
are really two distinct cases: a declaration associated with a binding
and a local declaration separate from the binding. The former differs
because it not only describes the type of values which the variable will
assume, but also permits using a specialized representation for the
variable's value cell.
I don't feel good about this because I'm afraid it would encourage users
to make the incorrect assumption that a local declaration is just as good
as a binding declaration. There will also be some performance penalty in
the compiler for looking up type declarations on a local declaration stack
instead of just having it as part of the variable table entry.
I don't understand why you think local declarations forbid specialized
representations (within the scope of the declaration) and I don't understand
why you think a local declaration is somehow inferior to a binding declaration.
It seems to me that a type declaration provides some information to the compiler,
and what the compiler does with it is not really the business of the Common Lisp
language specification, and is also rather difficult to discuss without referring
to a specific compiler.
> Benefits:
>
> The above example will not have to be written in the following silly way,
> which only works if x and y are used read-only:
>
> (if (and (typep x 'fixnum) (typep y 'fixnum))
> (let ((x x) (y y))
> (declare (fixnum x y))
> ...algorithm using x and y...)
> ...similar algorithm using x and y...)
But there might actually be an advantage to writing it this way. If you
are compiling for a conventional machine and the declarations are because
you want the most efficient code generated, then it may be worthwhile to
move the value to a fixnum cell rather than to reference it from a cell
that can hold a tagged object.
I'd rather that the compiler make this transformation, given the information
it needs to be able to do so, than that the users be required to do it by
hand. Of course, I'd rather that no one ever need to do type declarations
by hand in the first place.
∂20-Sep-88 1817 CL-Cleanup-mailer Re: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:17:17 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 18:10:29 PDT
Date: 20 Sep 88 18:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROLET-SEMANTICS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Mon, 1 Aug 88 13:57 EDT
To: piazza%lisp.DEC@decwrl.dec.com, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880920-181029-5268@Xerox>
I would be happy to see a new writeup which addressed Kent's concerns about the
writeup itself, which had only the SPECIAL-FORM proposal and a mention of the
:FLUSH option in the discussion section. Any chance of you giving it a shot in
the next week?
∂20-Sep-88 1817 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:17:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 18:13:07 PDT
Date: 20 Sep 88 18:13 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAGBODY-CONTENTS (version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Sun, 18 Sep 88 15:29 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
Message-ID: <880920-181307-5271@Xerox>
(tagbody
#\return (format t "return here...")
#\Newline (format t "newline here ...")
...)
might be a reason for disallowing characters.
I think this one is Ready for Release.
∂20-Sep-88 1817 Common-Lisp-Object-System-mailer Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:17:10 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:02:57 PDT
Date: 20 Sep 88 18:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYMBOL-MACROLET-DECLARE (version 1)
In-reply-to: Patrick Dussud <dussud@lucid.com>'s message of Tue, 13 Sep 88
11:41:59 PDT
To: Patrick Dussud <dussud@lucid.com>
cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
Common-Lisp-Object-System@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-180257-5257@Xerox>
We need to get this cleaned up in time to present to X3J13.
I think it is at least consistent with LET semantics to say that
(LOCALLY (DECLARE (SPECIAL X)) ...) introduces a new scope for X. Its consistent
with
(LET((X 4)) (DECLARE (SPECIAL X))
(LET ((X 3))
(LOCALLY (DECLARE (SPECIAL X)) X)))
returning 4.
I.e., add to the proposal something like:
Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
introduces a new scope for the variable(s) declared special, and will override
within its scope any SYMBOL-MACROLET.
∂20-Sep-88 1836 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:35:53 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 20 SEP 88 18:21:45 PDT
Date: 20 Sep 88 18:21 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 1 Sep 88
16:29:42 CDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <880920-182145-5298@Xerox>
The X3J13 body seems willing (eager) to give implementors the leeway to make
small concessions in semantics in the name of performance.
This seems like a relatively small concession given the negative association
with the assembly-language hacker's anathema of "self-modifying code".
I think it is marginally OK to leave the issue name alone....
Isn't this strongly related to FUNCTION-COERCE-TIME? I'm in favor of lazy
function coerce time for FUNCALL and agressive function coerce time for
car-of-form calling. That is, implementations should assume early binding when
it appears as the car of form, and late binding when it appears 'FOO. If you
really want late binding, you can say (FUNCALL 'FOO x y), right?
I don't know if it makes sense to link the issues, but the two together make
more sense than either one alone.
∂20-Sep-88 1836 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 18:36:02 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 18:24:46 PDT
Date: Tue, 20 Sep 88 18:24 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Eric Benson <eb@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809210010.AA01124@blacksox>
Message-ID: <19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Tue, 20 Sep 88 17:10:12 pdt
From: Eric Benson <eb@lucid.com>
I agree completely with Moon's criticism of this proposal.
I also agree with Moon's criticism. I think a simpler mechanism for
this should be easy to discover.
I would
prefer to remove #, and its functionality altogether from the
language. It just isn't that important. I have yet to see any use for
#, which could not have been achieved by other means.
But this last statement just isn't true. Here is an example:
I want to be able to define a function, and have one of the function's
"quoted constants" be a little table, lets say an array. I need to
compute the array at load time, using my own special code, because I
need to arrange for some of the functions to share arrays. Now, if I
was just writing a defun, I could say:
(defun a-little-function (x)
(aref #,(get-table-for 'a-little-function '(x))
x))
But, of course #, doesn't work inside of macros.
Before proposing that I use a gensym, and somehow arrange to set
its value to the right thing, consider that portable efficiency
of the resulting code is almost guaranteed to be an issue whenever
anyone wants to do something like this.
-------
∂20-Sep-88 1909 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 19:09:29 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462874; Tue 20-Sep-88 22:07:55 EDT
Date: Tue, 20 Sep 88 22:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 3)
To: chapman%aitg.DEC@decwrl.dec.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809200106.AA05432@decwrl.dec.com>,
<8809191413.AA03664@decwrl.dec.com>
Message-ID: <880920220739.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Since there is now a proposal on the table for dealing with START and
END arguments, why not just strike all wording in this proposal which
deals with those arguments. That way, we won't have to worry about the
order in which the incompatible proposals are approved.
-kmp
ps If you're not on CL-Cleanup and so didn't see a copy, let me know
and I'll forward you one.
∂20-Sep-88 1920 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 19:20:22 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462882; Tue 20-Sep-88 22:18:37 EDT
Date: Tue, 20 Sep 88 22:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Gray@DSG.csc.ti.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880921005536.3.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880918202212.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880920221824.5.KMP@GRYPHON.SCRC.Symbolics.COM>
I generally support the proposal DECLARE-TYPE-FREE:ALLOW and concur with
Moon's comments in subsequent discussion to date.
To me, the issue is really this: The programmer knows many things about
his programs. The more things he tells the compiler, the less the compiler
has to infer; in some cases, the information is invaluable because the
compiler would not be able to ever infer it. We should provide ways for
users to say things about their programs when there is a reasonable
expectation that the compiler can do something useful with the information.
It seems clear that some compiler writers want to do useful things with
the information in we're talking about letting the user provide, so I think
we should allow it.
∂20-Sep-88 1921 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 19:21:25 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05011g; Tue, 20 Sep 88 18:19:33 PST
Received: by bhopal id AA20490g; Tue, 20 Sep 88 19:19:01 PDT
Date: Tue, 20 Sep 88 19:19:01 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8809210219.AA20490@bhopal>
To: Gregor.pa@Xerox.COM
Cc: eb@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 20 Sep 88 18:24 PDT <19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
I would
prefer to remove #, and its functionality altogether from the
language. It just isn't that important. I have yet to see any use for
#, which could not have been achieved by other means.
Sigh. I simply don't believe this claim. ...
But this last statement just isn't true. Here is an example:
Excuse me for being pedantic, but how can either of you claim to know
what EB has seen? If *you* have seen such uses, that's interesting,
but doesn't invalidate his observation, which is (I think) intended to
lend support to the argument that such uses are very rare or
non-existant.
... I could say:
(defun a-little-function (x)
(aref #,(get-table-for 'a-little-function '(x))
x))
But would you, or has anyone? That's the real question. The last
time I looked, there were exactly two uses of #, in Lucid's product--
both to setup something like *software-version* (I forget the exact
details). Surely #, is overkill for such uses.
We can provide lots of efficiency hooks that no one will ever use.
I think the burden of proof here is for someone to show some *real*
examples of where #, is a clear win.
jlm
∂20-Sep-88 1944 CL-Compiler-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 19:44:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 462890; 20 Sep 88 22:41:36 EDT
Date: Tue, 20 Sep 88 22:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: jlm@lucid.com
cc: Gregor.pa@Xerox.COM, eb@SAIL.Stanford.EDU,
Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
cl-compiler@sail.stanford.edu, kmp@STONY-BROOK.SCRC.Symbolics.COM,
cl-cleanup@sail.stanford.edu
In-Reply-To: <8809210219.AA20490@bhopal>
Message-ID: <880920224119.6.KMP@GRYPHON.SCRC.Symbolics.COM>
It doesn't make any sense to talk about the number of uses that a primitive has.
PROGV isn't used that much either -- many users never use it. Yet it's generally
acknowledged to be a good thing just for those few places where it's needed.
The situations Gregor and I are talking about are rare by one metric: lines of
code. Maybe #, will occur only once in a portable implementation of CLOS. (Though
my guess is much higher -- perhaps even 2 or 3 times. :-) But without it, it may
be hard to make such a portable implementation.
I also needed the feature for my Fortran->Lisp translator, 10 years ago in Maclisp.
It allows one to emulate ``linking.'' If I wrote the program again today in
Common Lisp, I couldn't do as well because at least the Maclisp facility provided
for an interface to macros.
Are you going to count the number of lines of code (fewer than 10, probably),
the number of programs that write DEFMETHOD or Fortran SUBROUTINE (probably in
the thousands), or the number of times those programs are called (conservatively
in the hundreds of thousands) when you count the frequency of use?
If #, is not used a lot, it's not because it's some low-level grungy that only a
few people have the poor taste to use. It's because the language designers haven't
gotten their act together enough to give it a portable definition that people can
write about.
Currently, #, is defined in a non-portable way that makes it a low-level grungy
thing, but in fact it is an abstract concept that I think should be fundamental
to everyone's knowledge of programming.
Programming is about decision-making. Some decisions are delayed longer than others.
One key to making decisions at the right time is having access to being able to
name the times at which decisions might be made. It's ludicrous to think that only
at toplevel would there be decisions that need to be postponed until runtime and
that EVAL-WHEN should suffice. It's ludicrous to say that every postponed decision
should need a first-class name. Some decisions in the middle of a program body
need to be postponed without sacrificing anonymity. #, provides a natural
mechanism for, at any point in a programming, saying "I won't know what goes here
at compilation time, but the instant I get ahold of the runtime environment I can
tell you the object I'm talking about." There's nothing low-level or shameful about
that.
∂20-Sep-88 1959 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 19:59:52 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05065g; Tue, 20 Sep 88 18:57:50 PST
Received: by rainbow-warrior id AA19086g; Tue, 20 Sep 88 19:56:11 PDT
Date: Tue, 20 Sep 88 19:56:11 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809210256.AA19086@rainbow-warrior>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 19:46 EDT <19880920234609.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
I completely agree with Moon on this topic. We don't need the complication
intoduced by this new proposal.
I also agree that the cleanup committee needs to come up with a proposal for
an environment argument, able to distinguish between compile-file and core
processing.
Patrick.
∂20-Sep-88 2001 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:01:51 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462902; Tue 20-Sep-88 23:00:16 EDT
Date: Tue, 20 Sep 88 22:59 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DOTTED-MACRO-FORMS (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, goldman@VAXA.ISI.EDU
In-Reply-To: <880914-220022-1881@Xerox>
Message-ID: <880920225958.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 14 Sep 88 22:00 PDT
From: masinter.pa@Xerox.COM
... I am in favor of DOTTED-MACRO-FORMS:ALLOW, with an addendum that
a comment be added to the standard where appropriate which says that
such usage, while allowed, is not good progamming practice and should
be discouraged.
Then why not just make it "an error" (per EXPLICITLY-VAGUE) and let
implementors phase it out over a period of time they feel is comfortable?
I'm generally not a fan of saying things are "legal but discouraged",
and especially I don't want to get into a lot of that in a standard we
want to hang around for a while.
∂20-Sep-88 2004 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:04:50 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 20 SEP 88 19:42:12 PDT
Date: Tue, 20 Sep 88 19:41 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Jim McDonald <jlm@lucid.com>
cc: eb@SAIL.Stanford.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM,
sandra%defun@cs.utah.edu, cl-compiler@sail.stanford.edu,
kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-cleanup@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809210219.AA20490@bhopal>
Message-ID: <19880921024150.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Tue, 20 Sep 88 19:19:01 PDT
From: Jim McDonald <jlm@lucid.com>
Excuse me for being pedantic, but how can either of you claim to know
what EB has seen? If *you* have seen such uses, that's interesting,
but doesn't invalidate his observation, which is (I think) intended to
lend support to the argument that such uses are very rare or
non-existant.
Actually, I can know that EB has seen this case. I have talked with him
about it before.
... I could say:
(defun a-little-function (x)
(aref #,(get-table-for 'a-little-function '(x))
x))
But would you, or has anyone? That's the real question.
Yes, I would if only I could. In writing PCL, the fact that there
isn't a load-time-eval facility in the language has caused me a great
deal of pain. The little code fragment above is the distillation of
what I have wanted to do in several places. As an example, one way to
implement permutation vectors is to have the PV cache just be in the
method functions that need them, this requires load time eval facility.
As another example, one way to provide certain kinds of programming
environment hook is to have method functions point back at the method
object they are associated with, load-time-eval can help arrange this.
The last
time I looked, there were exactly two uses of #, in Lucid's product--
both to setup something like *software-version* (I forget the exact
details). Surely #, is overkill for such uses.
I must admit that this datapoint doesn't mean too much too me, since #,
doesn't work in Lucid Lisp.
-------
∂20-Sep-88 2008 CL-Cleanup-mailer Issue: SYMBOL-MACROLET-DECLARE (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:08:49 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA05077g; Tue, 20 Sep 88 19:06:13 PST
Received: by rainbow-warrior id AA19120g; Tue, 20 Sep 88 20:04:34 PDT
Date: Tue, 20 Sep 88 20:04:34 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809210304.AA19120@rainbow-warrior>
To: masinter.pa@Xerox.COM
Cc: piazza%lisp.DEC@decwrl.dec.com, Moon@stony-brook.scrc.symbolics.com,
Common-Lisp-Object-System@SAIL.STANFORD.EDU,
cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 20 Sep 88 18:02 PDT <880920-180257-5257@Xerox>
Subject: Issue: SYMBOL-MACROLET-DECLARE (version 1)
Date: 20 Sep 88 18:02 PDT
From: masinter.pa@Xerox.COM
We need to get this cleaned up in time to present to X3J13.
Clarify that, within a SYMBOL-MACROLET, a nested LOCALLY with a DECLARE SPECIAL
introduces a new scope for the variable(s) declared special, and will override
within its scope any SYMBOL-MACROLET.
I agree with this. We should also specify that SPECIAL shouldn't be used in
the declaration part of a symbol-macrolet. Locally special declaration are
fine.
Patrick.
∂20-Sep-88 2029 CL-Cleanup-mailer Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:29:42 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 462926; Tue 20-Sep-88 23:28:12 EDT
Date: Tue, 20 Sep 88 23:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ROOM-DEFAULT-ARGUMENT (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19880913000129.5.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<880919-234035-3227@Xerox>
Message-ID: <880920232753.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 12 Sep 88 20:01 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... can't we just get rid of ROOM entirely? I think it never
should have been adopted from Zetalisp into Common Lisp in the
first place.
Macsyma uses it (to allow users to do from Macsyma what Lisp users
can do from Lisp).
Just as STEP doesn't replace the need for a real metering system, so
ROOM doesn't replace the need for better storage-management facilities,
but it gives you someplace to start from when you're working late and no
one is answering the phone on the customer service lines. I as a
Macsyma implementor was certainly grateful to have it.
Date: 19 Sep 88 23:40 PDT
From: masinter.pa@Xerox.COM
... Imagine two other proposals:
ROOM-DEFAULT-ARGUMENT:MAKE-EXPLICITLY-VAGUE (what ROOM does and what its
arguments beyond (ROOM) do are non-portable),
ROOM-DEFAULT-ARGUMENT:REMOVE (remove ROOM from the standard)
ROOM-DEFAULT-ARGUMENT:MAKE-KEYWORD (implementations can add arbitrary keywords
to ROOM, that can be interpreted however they want, except that they have to
(ROOM &ALLOW-OTHER-KEYS)).
My vote: I'd go for MAKE-EXPLICITLY-VAGUE first and ALLOW-OTHER-KEYS second
over the other two.
There are interesting but from the point of view of Macsyma, it was
useful to have at least some selective ability beyond the `no arguments'
case. I wouldn't mind the ALLOW-OTHER-KEYS proposal if you made at least
one of the keywords portable. How about
ROOM &key (VERBOSE ':DEFAULT) &allow-other-keys
where VERBOSE compatible with my proposal for what the optional argument
should do in the current syntax?
∂20-Sep-88 2044 CL-Cleanup-mailer message references
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 20:43:56 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05110g; Tue, 20 Sep 88 19:42:09 PST
Received: by bhopal id AA20839g; Tue, 20 Sep 88 20:41:31 PDT
Date: Tue, 20 Sep 88 20:41:31 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809210341.AA20839@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 15:08 EDT <19880920190805.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: message references
re: Date: Tue, 20 Sep 88 10:44:45 PDT
From: Jon L White <jonl@lucid.com>
Incidentally, I know we thrashed this issue out on Common-Lisp@SU-AI
some months ago; and I remember initiating the discussion with a query
msg to find out how other people felt about the issue. However your
"References" field shows only the very cryptic:
<8807200836.AA02976@bhopal.lucid.com>,
<19880719152249.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<19880719213809.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM>,
<870402170955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I've noticed that this kind of encryption always occurs whe Symbolics
folks try to reference prior mail; it must be some kind of "feature"
in the Symbolics mailer?
Those message-IDs follow the Internet standard for mail and were
generated by the original sender, not by my reply. There is no
encryption going on. There is nothing Symbolics-specific going on. I
have no control over these IDs, except possibly for the ones on the
messages that I sent originally.
. . .
You use Unix, don't you? I'm surprised that it doesn't implement the
Internet standard for mail.
No, I don't use Unix mailer. The emacs/RMAIL I use prepares a header
summary that includes the human readable information, but not any of the
"encryption" stuff. It's just that as a social convention, most other
folks include human readable pointers when making reference to previous
mail dialogue. Is the exclusive use of the message-ID just a Symbolics
social convention?
Also, I (and many others) don't include the message-ID's when referring to
past discussions, except insofar as mail Reply conventions install it. Does
this cause a difficulty for you folks at Symbolics?
-- JonL --
∂20-Sep-88 2126 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88 21:26:24 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA20720; Tue, 20 Sep 88 22:24:53 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA00814; Tue, 20 Sep 88 22:24:37 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809210424.AA00814@defun.utah.edu>
Date: Tue, 20 Sep 88 22:24:35 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 20 Sep 88 19:46 EDT
Sigh -- it seems like we've already been through this whole debate
at least a half dozen times on the cl-compiler mailing list, and now
we're back right where we started.
To sum up, we started with four options:
(1) Get rid of #, entirely.
(2) Keep #, as currently defined but do not make the hook user-visible.
(3) Some variant of Moon's original proposal.
(4) Some variant of Pitman's original proposal.
A number of us (including myself) prefer option (1), but others
indicated that they thought removing #, from the language would be
unacceptable. The next most popular option was (4), defining a new
special form. However, Pitman's proposal had some serious problems;
it did not clearly define what would happen in the presence of shared
code, for example. Even more importantly, nobody has suggested how to
implement the semantics it proposes other than by requiring the
interpreter to do a preprocessing codewalk, which would be a very
major change for some implementations. Hence my revised proposal to
address those problems.
So now we still have people expressing support for options (1), (3),
and (4); and each of these alternatives has also invoked vehement
disapproval. There remains alternative (2), which is the compiler
committee's fallback position. If we are unable to reach some
consensus and compromise about either removing #, or extending its
functionality, at the very least we need to clarify the status quo by
explicitly stating that #, must appear in a QUOTEd expression and that
it isn't really just like #..
-Sandra
-------
∂20-Sep-88 2131 CL-Cleanup-mailer Re: message references
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Sep 88 21:31:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 20 SEP 88 21:30:21 PDT
From: masinter.PA@Xerox.COM
Date: 20 Sep 88 21:28:12 PDT
Subject: Re: message references
To: jonl@lucid.com
cc: cl-cleanup@sail.stanford.edu
In-reply-to: a lot of grouchy messages about an inconsequential topic like what
the in-reply-to field of the message headers says
Message-ID: <880920-213021-5496@Xerox>
Please don't.
(Discuss this here.)
∂20-Sep-88 2132 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Sep 88 21:32:09 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA20745; Tue, 20 Sep 88 22:30:43 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA00829; Tue, 20 Sep 88 22:30:40 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809210430.AA00829@defun.utah.edu>
Date: Tue, 20 Sep 88 22:30:38 MDT
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-compiler@sail.stanford.edu, kmp@stony-brook.scrc.symbolics.com,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 20 Sep 88 19:46 EDT
> Date: Tue, 20 Sep 88 19:46 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> This function needs a way to tell whether a COMPILE-FILE is in
> progress or not (as does CLOS); I hope that the compiler committee is
> going to propose that the environment argument to macros can be used for
> this purpose. Symbolics Genera currently uses a special variable to
> convey this information, which has all the bugs that dynamic scoping
> always has.
This is not on our list of pending issues, but feel free to submit a
proposal if you have something specific in mind. The same goes for
anybody else who has a nit to pick relating to compilation issues,
that we haven't gotten around to yet. Unfortunately, I'm not a mind
reader. :-(
-Sandra
-------
∂20-Sep-88 2326 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Sep 88 23:26:26 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05164g; Tue, 20 Sep 88 22:24:46 PST
Received: by blacksox id AA01147g; Tue, 20 Sep 88 23:22:29 pdt
Date: Tue, 20 Sep 88 23:22:29 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809210622.AA01147@blacksox>
To: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Tue, 20 Sep 88 19:41 PDT <19880921024150.5.GREGOR@PORTNOY.parc.xerox.com>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Oh dear. I guess I should have just said that I support Moon's
criticism and left it at that. I will support a proposal that
formalizes the current expected behavior of #, and provides functional
access as well (the magic cookie cutter). I just think we could do
without it.
∂21-Sep-88 0035 CL-Cleanup-mailer ELIMINATE-FORCED-CONSING
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 00:35:52 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05198g; Tue, 20 Sep 88 23:34:11 PST
Received: by bhopal id AA21465g; Wed, 21 Sep 88 00:33:40 PDT
Date: Wed, 21 Sep 88 00:33:40 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809210733.AA21465@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 14 Sep 88 22:10 PDT <880914-221131-1891@Xerox>
Subject: ELIMINATE-FORCED-CONSING
I agree with your prognosis.
Specifically, I know of important companies that are trying to deliver
Lisp-written programs to be competitive with C-written ones, and their
programmers believe (rightly or wrongly) that they must do cons-free
programming. So it is a serious problem that can't be completely
ignored. Additionally, I agree with your conjecture:
In my mind, making CL more complicated is a very high cost.
and would add to it that making cleanup proposals more complicated
will be a very high cost. There's only so much we can do betwen
now and January.
-- JonL --
∂21-Sep-88 0052 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 00:52:15 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 00:50:20 PDT
Date: 21 Sep 88 00:50 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DOTTED-MACRO-FORMS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 20 Sep 88 22:59 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU, goldman@VAXA.ISI.EDU
Message-ID: <880921-005020-5624@Xerox>
There's a category of programs that are "usually bad style except when they're
not". I have a harder time defining when that is, but I think dotted macro forms
falls into that category. There may be a few occasions where saying (frob a b .
c) where you know frob is a macro with an &REST argument is a good idea. I think
we could allow it in the standard, it wouldn't cost any implementations any
performance, I wouldn't want students normally writing their homework that way,
but it might occasionally be just the right thing.
But I don't care much....
∂21-Sep-88 0111 CL-Cleanup-mailer Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 01:11:18 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 01:02:33 PDT
Date: 21 Sep 88 01:02 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
to: cl-cleanup@sail.stanford.edu
Message-ID: <880921-010233-5636@Xerox>
This is Peck's proposal. I mainly edited it to put it in third instead of first
person, moved a few things around to fit the proposal format a bit better.
!
Subject: New issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
Issue: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE
References: CLtL page 316
Category: CHANGE
Edit history: 20-Sep-88, Version 1, Peck
21-Sep-88, Version 2, Masinter, minor revisions
Problem description:
Currently, defstruct constructor functions can be either the default
constructor function, with *only* keyword arguments, or it can be a
so-called "By Order of Arguments" constructor function with explicitly
*no* keyword arguments. Other functions in Common Lisp allow a free
mix of required, optional, and keyword arguments.
With the current restriction, it is necessary to hand code a function that
will accept optional and keyword arguments and parse the supplied-p
variables explicitly. Even so, it is not obvious to the casual programmer
how to provide the same semantics as defstruct does with respect to default
values and the defstruct init-forms.
Proposal: DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE:ALLOW-KEY
Allow combination of &OPTIONAL, &KEY and &AUX arguments in
constructor forms of defstructs.
The current wording in CLtL (p314):
"In addition, the keywords &optional, &rest, and &aux are recognised
in the argument list. They work in the way you might expect ..."
would be extended accordingly.
Example:
It should be possible to write forms like this:
(defstruct (foo (:constructor CREATE-FOO (a &optional b (c 'sea)
&key (d 2)
&aux e (f 'eff))))
(a 1) (b 2) (c 3) (d 4) (e 5) (f 6))
(create-foo 10) => #S(foo a 10 b 2 c sea d 2 e nil f eff)
(create-foo 10 'bee 'see :d 'dee) => #S(foo a 10 b bee c see d dee e nil f eff)
Rationale:
This is a logical extension of the specification which makes some
programming easier.
Current practice:
Some implementations to signal an error. Envos Medley (Xerox Common Lisp)
implements the proposed behavior.
Cost to Implementors:
The modifications to allow intermixed keywords and optionals in implementations
that don't already are likely simple.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
The current situation is non-intuitive and needless restrictive.
Benefits:
Much easier for users to write the constructor function they want.
Probably implementation code would be reduced, since this would no
longer be an error.
Esthetics:
Minor improvement since it removes a needless restriction.
Discussion:
Possibly references to "By-position", "positional", and "By Order of
Arguments" constructor function might need to be changed to something else in
the standard. (They can still be called BOA-constructors, though, right? :-)
∂21-Sep-88 0135 CL-Cleanup-mailer Issue: ALIST-NIL (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 01:35:04 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 01:33:45 PDT
Date: 21 Sep 88 01:33 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ALIST-NIL (Version 3)
To: cl-cleanup@sail.stanford.edu
Message-ID: <880921-013345-5657@Xerox>
Ready for release? (Only reply if you have complaints, preferably with a new
version....)
I changed Kent's tentative description of 'remove or justify' in the discussion
into more like an endorsement.
!
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
4-Sep-88, Version 2 by Masinter (reflect discussion)
21-Sep-88, Version 3 by Masinter (minor edits)
Problem Description:
NIL is permitted to be an element of an a-list but nothing useful
can be done with such an element. This is confusing to users.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
No motivation in CLtL is given for NIL being allowed in an a-list.
The description of a-lists seem needlessly complicated by this feature.
FIND (with a :KEY of #'CAR) and ASSOC (with no key) are almost identical
except for their treatment of this issue. If no one makes significant
use of the feature, it would be better to be able to simplify the
relationship between these functions.
Current Practice:
All valid implementations allow NIL.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which the author is able to guess this
feature might be used:
#1: A user might want a leading NIL on an a-list so that if the list
were empty, there'd still be a tail to which cells could be attached
in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that this is more
clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) ENTRY) ;Something unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT,
RASSOC-IF and RASSOC-IF-NOT depending on the predicate used.
Cost of Non-Adoption:
There only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
Simplified documentation. May allow ASSOC to be faster if it is no
longer necessary to check explicitly for NIL.
Aesthetics:
This change would simplify the language.
Discussion:
The description of association lists is currently cluttered by this
unmotivated feature; no strong motivation or widespread use
of the feature has been found.
Putting a NIL in an alist as a way of removing the element might
be simpler than putting some otherwise useless CONS, and allows
for a quick (remove NIL alist).
Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations
of ASSOC where this feature didn't cost in performance, at least
in the special case where the predicate was EQ or EQL.
∂21-Sep-88 0148 CL-Cleanup-mailer Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 01:48:23 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 01:47:01 PDT
Date: 21 Sep 88 01:47 PDT
From: masinter.pa@Xerox.COM
to: CL-CLEANUP@Sail.Stanford.Edu
cc: Masinter.pa@Xerox.COM
line-fold: NO
Subject: Issue: ARGUMENTS-UNDERSPECIFIED (Version 4)
Message-ID: <880921-014701-5665@Xerox>
Ready for release?
!
Issue: ARGUMENTS-UNDERSPECIFIED
References: LOGBITP (p 224), MAKE-DISPATCH-MACRO-CHARACTER (p 363),
MAKE-HASH-TABLE (p 283), MAKE-SEQUENCE (p 249), READ (p 375)
MAKE-STRING (p 302), NTHCDR (p 267), PARSE-INTEGER (p 381),
SET (p 92)
Issue: RANGE-OF-START-END-PARAMETERS.
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
4-Sep-88, version 2 by Masinter
19-Sept-88, Version 3 by Chapman
21-Sep-88, Version 4 by Masinter
Problem Description:
The descriptions of LOGBITP, MAKE-DISPATCH-MACRO-CHARACTER, READ, SET,
MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING, NTHCDR, and PARSE-INTEGER
are not clear about the types of the arguments supplied to these
constructs.
Proposal (ARGUMENTS-UNDERSPECIFIED:SPECIFY)
Clarify that the arguments for the listed constructs are as follows:
Construct Argument Type
LOGBITP index non-negative integer
MAKE-DISPATCH-MACRO-CHARACTER char character
MAKE-HASH-TABLE size non-negative integer
MAKE-SEQUENCE size non-negative integer
MAKE-SEQUENCE type type specifier
MAKE-STRING size non-negative integer
MAKE-STRING initial-element string-char
NTHCDR n non-negative integer
SET-SYNTAX-FROM-CHAR to-char,from-char
characters
READ and others eof-value any value
SET value any value
(MAKE-HASH-TABLE, MAKE-SEQUENCE, MAKE-STRING have additional constraints on
their respective SIZE arguments; for example, MAKE-STRING may detect an error if
SIZE is greater than or equal to ARRAY-DIMENSION-LIMIT. Some additional
restriction on the range of characters which can have syntax in readtables
and are allowable to MAKE-DISPATCH-MACRO-CHARACTER SET-SYNTAX-FROM-CHAR might
be required in some other proposal.)
Rationale:
This clarification allows predictible results to occur when
arguments are supplied to these constructs.
Current Practice:
This proposal seems to be in line with current implementations.
Cost to Implementors:
None, since this is consistent with current practice.
Cost to Users:
None, since this is consistent with current practice.
Benefits:
This clarification will assist users in writing portable code.
Aesthetics:
The standard would be less clean were the allowed ranges of its functions not
specified.
Discussion:
There is a separate cleanup proposal RANGE-OF-START-END-PARAMETERS which
addresses a possible incompatible change. This proposal contains what we
think are non-controversial clarifications.
∂21-Sep-88 0240 CL-Cleanup-mailer Re: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 02:40:38 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 02:39:17 PDT
Date: 21 Sep 88 02:39 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CLOSED-STREAM-OPERATIONS (Version 1)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Wed, 7 Sep 88 21:41 EDT
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880921-023917-5692@Xerox>
Are we agreed that functions that take streams and coerce them to pathnames are
required to take closed streams and recall the pathname to which the stream was
originally attached? E.g., does
(with-open-file (x name)
(pathname x))
return the 'same' value as
(pathname (with-open-file (x name) x))
?
I think to sort this out further, we need a complete list of functions that
accept streams, and a blow-by-blow on whether closed streams are OK or not.
I think we also need a separate CLOSE-CONSTRUCTED-STREAM issue which outlines
the operations of CLOSE on constructed streams. I have no problems accepting
Moon's preferences.
∂21-Sep-88 0249 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 02:49:00 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 02:47:39 PDT
Date: 21 Sep 88 02:47 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: TYPE-OF-UNDERCONSTRAINED
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Tue, 13 Sep 88 10:22 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880921-024739-5696@Xerox>
This is in response to mail under COERCE-FROM-TYPE and TYPE-OF. I would prefer
to constrain TYPE-OF to be at least as specific as (CLASS-NAME (CLASS-OF x)).
I'm less sure what to do about instances of unnamed classes; the Medley way
would be to return the class itself for an otherwise nameless class.
This would disallow what is otherwise "legal" now: namely to have TYPE-OF return
T for everything but structure instances.
I think it probably is reasonable also to constrain TYPE-OF to be something that
SUBTYPEP can deal with. (cf SUBTYPEP-TOO-VAGUE).
If I don't here any objections, I'll try to write this up when I get back that
far in the alphabet.
Meanwhile, I'll make a pass on COERCE-INCOMPLETE.
∂21-Sep-88 0306 CL-Cleanup-mailer Issue: COERCE-INCOMPLETE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 03:06:32 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 21 SEP 88 03:05:12 PDT
Date: 21 Sep 88 03:05 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: COERCE-INCOMPLETE (Version 1)
To: cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880921-030512-5704@Xerox>
I can't decide about this one (maybe its the wrong time of day again.) I'd like
to hear some opinions from the rest of you:
extend coerce to handle more types?
Add an extra argument?
Make COERCE generic?
Make COERCE take classes as well as type names?
∂21-Sep-88 0319 CL-Cleanup-mailer Re: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 03:19:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 03:17:49 PDT
Date: 21 Sep 88 03:17 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message of
Wed, 14 Sep 88 16:27 EDT
To: CL-Cleanup@sail.stanford.edu
Message-ID: <880921-031749-5707@Xerox>
I think Version 1 is Ready for Release; that is, none of the minor edits I was
tempted to make to it would improve it.
∂21-Sep-88 0845 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 08:45:25 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463154; Wed 21-Sep-88 11:43:16 EDT
Date: Wed, 21 Sep 88 11:43 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAGBODY-CONTENTS (version 1)
To: masinter.pa@Xerox.COM
cc: vanroggen%aitg.DEC@decwrl.dec.com, cl-cleanup@sail.stanford.edu
In-Reply-To: <880920-181307-5271@Xerox>
Message-ID: <19880921154319.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 20 Sep 88 18:13 PDT
From: masinter.pa@Xerox.COM
(tagbody
#\return (format t "return here...")
#\Newline (format t "newline here ...")
...)
might be a reason for disallowing characters.
Good point.
I think this one is Ready for Release.
Agreed.
∂21-Sep-88 0906 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 09:06:20 PDT
Received: by ti.com id AA02684; Wed, 21 Sep 88 11:03:55 CDT
Received: from Kelvin by tilde id AA26526; Wed, 21 Sep 88 10:54:55 CDT
Message-Id: <2799849365-13670868@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88 10:56:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
In-Reply-To: Msg of Tue, 20 Sep 88 20:55 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> Should add that if there is both a binding declaration and a local
> declaration for the type of the same variable, then, within the scope of
> the local declaration, it is an error for the variable to contain a value
> which is not a member of the intersection of the two types. (This implies
> that it would be desirable for the compiler to complain if the two types
> are disjoint.)
>
> True. Does the proposal really need to say this? It's a pretty obvious
> consequence.
It may be obvious to us, but it probably wouldn't be to the average user.
Anyway, I had to stop and think about whether it should be a subtype or
just non-disjoint.
> I don't understand why you think local declarations forbid specialized
> representations (within the scope of the declaration)
It doesn't forbid it, but in order to do it, the compiler would have to
copy the value, but it can only do that if it knows that it is not SETQ'd.
It also would require the compiler to count the number of references to
decide if the copy is worthwhile. Thus, while it would be possible for a
compiler to do this, it is unlikely for an implementor to go to that much
trouble.
> It seems to me that a type declaration provides some information to the compiler,
> and what the compiler does with it is not really the business of the Common Lisp
> language specification
Assuming of course that the information is really useful to a compiler;
there wouldn't be much point otherwise.
∂21-Sep-88 0923 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 09:23:04 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463200; Wed 21-Sep-88 12:21:12 EDT
Date: Wed, 21 Sep 88 12:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
To: Gray@DSG.csc.ti.com, Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799849365-13670868@Kelvin>
Message-ID: <880921122104.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 21 Sep 88 10:56:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> Should add that if there is both a binding declaration and a local
> declaration for the type of the same variable, then, within the scope of
> the local declaration, it is an error for the variable to contain a value
> which is not a member of the intersection of the two types. (This implies
> that it would be desirable for the compiler to complain if the two types
> are disjoint.)
>
> True. Does the proposal really need to say this? It's a pretty obvious
> consequence.
It may be obvious to us, but it probably wouldn't be to the average user.
Anyway, I had to stop and think about whether it should be a subtype or
just non-disjoint. ...
Well, it just occurred to me that there is an interpretation to even a disjoint
type declaration. Consider that the paranoid programmer might try to help out
the compiler's storage allocation phase by recycling a variable for a new type
using SETQ because he knows it won't be used further in the program but doesn't
know for sure that the compiler will realize this fact. Here's an example of
that style:
(DEFUN FOO (X Y)
(DECLARE (FLOAT X Y))
(LET ((SUM (+ X Y)))
(DECLARE (FLOAT SUM))
(COND ((> SUM 3.0)
(LOCALLY (DECLARE (FIXNUM X))
; X won't be used any more, so let's recycle its home...
(SETQ X (TRUNCATE SUM))
(+ (* X X) (* SUM Y))))
(T
(* X Y SUM)))))
∂21-Sep-88 0950 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 09:50:42 PDT
Received: by ti.com id AA02980; Wed, 21 Sep 88 11:48:10 CDT
Received: from Kelvin by tilde id AA27381; Wed, 21 Sep 88 11:35:57 CDT
Message-Id: <2799851831-13818993@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88 11:37:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Tue, 20 Sep 88 19:46 EDT from "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
> The new mechanism has all sorts of problems with multiple evaluation
> that #, did not have. The semantics of #, were very clear, if somewhat
> off the wall.
Since neither the MIT Lisp Machine manual nor CLtL correctly document how
to use #, it would hardly seem that the semantics are "very clear". The
question of multiple evaluation applies to #, also, it just hasn't ever
been spelled out before.
> ... any implementation that
> formerly treated all constants as read-only now needs a way to label
> each constant as read-only or writable.
But #, never could be treated quite the same as other constants, since it
is constructed at load time instead of compile-time. The Explorer
write-protects ordinary constants, but not when #, is used.
> ... Since #, is a feature of LOAD rather than of EVAL, we don't
> need any new rules about what happens if you evaluate it twice. Since
> #, is a feature of LOAD rather than of EVAL, there is no issue of
> semantic incompatibility between the compiler and the interpreter.
#, is a feature of the reader that needs to cause both the loader
and evaluator to do something appropriate with it. Are you suggesting
that it is only permissible to use #, within an input file to
COMPILE-FILE?
> How to make the mechanism underlying #, available? This would be a
> function that receives a form and returns an object (I'd use the term
> "magic cookie" if I didn't hate it) which can be placed inside a quoted
> constant; by the time the program is loaded, that position in the quoted
> constant will contain the result of evaluating the form in the null
> lexical environment. It is only useful to call this function from
> macros.
Although this approach follows the way we happen to implement #, I don't
care for it because it seems to be institutionalizing an implementation
technique rather than focusing on the functionality to be provided.
I also had a negative initial reaction to the new-special-form proposal,
but my attempts to come up with something simpler only led me appreciate
it. There is still a valid question though of whether we want
#,exp <==> (LOAD-TIME-VALUE exp T)
or
'#,exp <==> (LOAD-TIME-VALUE exp T)
'(... #,exp ...) <==> (LOAD-TIME-VALUE (LIST ... exp ...) T)
I could go either way on that; the first way (as proposed) is much
simpler, but the second is consistent with current practice.
∂21-Sep-88 1006 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:06:37 PDT
Received: by ti.com id AA03090; Wed, 21 Sep 88 12:04:01 CDT
Received: from Kelvin by tilde id AA27566; Wed, 21 Sep 88 11:49:12 CDT
Message-Id: <2799852627-13866831@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88 11:50:27 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 1)
In-Reply-To: Msg of Wed, 21 Sep 88 12:21 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Well, it just occurred to me that there is an interpretation to even a disjoint
> type declaration. Consider that the paranoid programmer might try to help out
> the compiler's storage allocation phase by recycling a variable for a new type
> using SETQ because he knows it won't be used further in the program but doesn't
> know for sure that the compiler will realize this fact. Here's an example of
> that style:
>
> (DEFUN FOO (X Y)
> (DECLARE (FLOAT X Y))
> (LET ((SUM (+ X Y)))
> (DECLARE (FLOAT SUM))
> (COND ((> SUM 3.0)
> (LOCALLY (DECLARE (FIXNUM X))
> ; X won't be used any more, so let's recycle its home...
> (SETQ X (TRUNCATE SUM))
> (+ (* X X) (* SUM Y))))
> (T
> (* X Y SUM)))))
Gag! This is an example of what we most definitely want to prohibit.
This is a highly misguided programming style and can be made meaningful
only if the compiler is prohibited from using specialized storage for
variables.
∂21-Sep-88 1036 CL-Cleanup-mailer Issue: FUNCTION-DECLARATION (version 1)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:35:57 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA22554; Wed, 21 Sep 88 10:34:34 PDT
Date: Wed, 21 Sep 88 10:34:34 PDT
Message-Id: <8809211734.AA22554@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: FUNCTION-DECLARATION (version 1)
Issue: FUNCTION-DECLARATION
References: CLtL pp 43 (Table 4-1), 158-159
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
Problem description:
CLtL permits ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
Proposal (FUNCTION-DECLARATION:DELETE)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that wasn't clearly possible without using the TYPE declaration.
Current Practice:
VAX LISP treats FUNCTION declarations as describing only function bindings.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations. Such code could not have been portable,
though.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
At first I had two proposals, FUNCTION-DECLARATION:DELETE and
FUNCTION-DECLARATION:FUNCTION-BINDING. The latter would be more compatible
with (believed likely) current usage, but I decided that the former
proposal was just plain better.
∂21-Sep-88 1050 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:50:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463291; Wed 21-Sep-88 13:48:18 EDT
Date: Wed, 21 Sep 88 13:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: David N Gray <Gray@DSG.csc.ti.com>
cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799851831-13818993@Kelvin>
Message-ID: <19880921174821.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 21 Sep 88 11:37:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> The new mechanism has all sorts of problems with multiple evaluation
> that #, did not have. The semantics of #, were very clear, if somewhat
> off the wall.
Since neither the MIT Lisp Machine manual nor CLtL correctly document how
to use #, it would hardly seem that the semantics are "very clear". The
question of multiple evaluation applies to #, also, it just hasn't ever
been spelled out before.
Since the evaluation happens at load time, how can it happen more than
once? If you load the same file again, you create a new object, you
don't "load the same object again." It's true that #, has always been
poorly documented, which is how we got into this mess in the first place.
> ... any implementation that
> formerly treated all constants as read-only now needs a way to label
> each constant as read-only or writable.
But #, never could be treated quite the same as other constants, since it
is constructed at load time instead of compile-time.
All constants are created at load time. Think about it; the output file
from COMPILE-FILE doesn't contain objects, it contains instructions to
the loader telling it how to create objects.
> ... Since #, is a feature of LOAD rather than of EVAL, we don't
> need any new rules about what happens if you evaluate it twice. Since
> #, is a feature of LOAD rather than of EVAL, there is no issue of
> semantic incompatibility between the compiler and the interpreter.
#, is a feature of the reader that needs to cause both the loader
and evaluator to do something appropriate with it. Are you suggesting
that it is only permissible to use #, within an input file to
COMPILE-FILE?
No, of course not. I'm saying that #, is a feature of the reader that
needs to cause the loader to do something appropriate with it. #, never
affects the evaluator, EVAL and COMPILE never see anything different when
#, is used than they would see normally.
> How to make the mechanism underlying #, available? This would be a
> function that receives a form and returns an object (I'd use the term
> "magic cookie" if I didn't hate it) which can be placed inside a quoted
> constant; by the time the program is loaded, that position in the quoted
> constant will contain the result of evaluating the form in the null
> lexical environment. It is only useful to call this function from
> macros.
Although this approach follows the way we happen to implement #, I don't
care for it because it seems to be institutionalizing an implementation
technique rather than focusing on the functionality to be provided.
That's exactly the opposite of what I thought I was doing, so I guess we're
not communicating very well.
I also had a negative initial reaction to the new-special-form proposal,
but my attempts to come up with something simpler only led me appreciate
it.
I sure can't understand why this issue is so hard.
∂21-Sep-88 1059 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 10:59:15 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA24142; Wed, 21 Sep 88 10:57:54 PDT
Message-Id: <8809211757.AA24142@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
Date: 21 Sep 88 13:55
To: cl-cleanup@sail.stanford.edu
Subject: SYMBOL-MACROLET-SEMANTICS (Version 2)
Status: For Internal Discussion
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion, and that ``recursive'' symbol macros
are an error. Specify that it is an error to try to SETQ a symbol macro.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Finally, the rule that SETQ of a symbol macro must be treated as a SETF of
the expansion seems to be a kludge which was introduced only to support a
code-walking version of SYMBOL-MACROLET. If SYMBOL-MACROLET were changed
to be a special form, this rule would no longer be needed, and should be
eliminated in order to make the distinction between symbol macros and
variables cleaner.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
∂21-Sep-88 1126 CL-Cleanup-mailer message references
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 11:26:33 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05596g; Wed, 21 Sep 88 10:24:51 PST
Received: by bhopal id AA01379g; Wed, 21 Sep 88 11:24:20 PDT
Date: Wed, 21 Sep 88 11:24:20 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809211824.AA01379@bhopal>
To: masinter.PA@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.PA@Xerox.COM's message of 20 Sep 88 21:28:12 PDT <880920-213021-5496@Xerox>
Subject: message references
re: . . . messages about an inconsequential topic like what
the in-reply-to field of the message headers says ...
I believe you've misunderstood something; the commentary about the
"References" section is not about "message headers" or anything
having to do with mail sytem protocols.
Rather, it is about the content of the section of Cleanup Proposals
called "References". Since these proposals are discussed at the
X3J13 meetings, and by persons who have no access to electronic
mail, then I'd hope the are in human-readable format, rather than
"encrypted" message-ID's.
See the form you passed out at the Fort Collins X3J13 meeting called
"Format for proposals to the cleanup committee (Version 13).
-- JonL --
∂21-Sep-88 1126 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 11:25:58 PDT
Received: from RIO-DE-JANEIRO.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463326; Wed 21-Sep-88 14:23:26 EDT
Date: Wed, 21 Sep 88 14:23 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: Gray@DSG.csc.ti.com, CL-Compiler@SAIL.Stanford.EDU,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880921174821.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880921142327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Date: Wed, 21 Sep 88 13:48 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... All constants are created at load time. Think about it; the output
file from COMPILE-FILE doesn't contain objects, it contains instructions
to the loader telling it how to create objects. ...
Not just how to create objects -- also to -find- objects. This is at the root
of my concern about whether #,(form) returns a modifiable object.
If you just write '(2 3 4) the compiler must figure out how to do the
construction from your declarative reference to the conjured structure.
It can't tell if you wrote: '#.(LOOP FOR X FROM 2 TO 4 COLLECT X) or
'#.(CDR FOUR-THINGS) or '(2 3 4) so it just does the best it can based
on the final result.
On the other hand, the #, facility provides you with a way to advise the
compiler about the actual code to be used in procuring the object. The
compiler can tell if sharing, modifiability, circularity, etc. is
important to you because it can blindly follow the instructions which you
have carefully written to express your exact requirements.
#, is not about constants. It is simply about delayed decision-making.
If I delay a decision until runtime, I don't have to return an immutable
object from a function. Why should I have to return an immutable object
if I can make the decision a little earlier (at load time)?
Indeed, the only reason that decisions made in the compiler can be construed
to be constants is exactly this unfortunate artifact of file compilation
which you address. If the compiler shared a huge address space with all
Lisps for all time, it could output pointers to actual objects and then
decisions about mutable objects could be made in the compiler. We accept
the file-model of a compiler as a limitation of existing systems and allow
anything done on the `compiler side' to be subject of funny restrictions
needed to allow you to represent your program to a file and have it
reconstructed, but since #, is not done on the compiler side, it should not
be subject to these restrictions.
I sure can't understand why this issue is so hard.
Me either. It seems crystal clear to me. :-)
∂21-Sep-88 1126 CL-Compiler-mailer Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 11:26:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463328; Wed 21-Sep-88 14:23:47 EDT
Date: Wed, 21 Sep 88 14:23 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Gregor.pa@Xerox.com, cl-compiler@sail.stanford.edu
In-Reply-To: <8809210430.AA00829@defun.utah.edu>
Message-ID: <19880921182349.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Tue, 20 Sep 88 22:30:38 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 20 Sep 88 19:46 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> This function needs a way to tell whether a COMPILE-FILE is in
> progress or not (as does CLOS); I hope that the compiler committee is
> going to propose that the environment argument to macros can be used for
> this purpose.
This is not on our list of pending issues, but feel free to submit a
proposal if you have something specific in mind.
Further examination shows that no proposal is necessary! X3J13 has already
voted to adopt 88-002R into the language, and pages 2-47 and 2-48 of 88-002R
already specify that this exists. However to avoid accusations of sneaking
things into the language behind the committee's back, I'll submit a clarification.
Issue: COMPILE-FILE-ENVIRONMENT
References: 88-002R pages 2-47 and 2-48
Category: CLARIFICATION
Edit history: Version 1, 21-Sep-1988, Moon
Problem description:
It may not be clear to everyone that as of the adoption of 88-002R in June,
there is an additional requirement on the semantics of the environment
argument to macro expander functions.
Proposal (COMPILE-FILE-ENVIRONMENT:CLARIFY):
Clarify that when COMPILE-FILE expands a macro invoked from the code
being compiled, the environment argument to the expander function
contains information that indicates that the macro expansion will be
used in the run-time environment, not in the compile-time environment.
This information is used by the FIND-CLASS and ENSURE-GENERIC-FUNCTION
functions, for example.
Clarify that when interpreted code is executed during COMPILE-FILE (this
might be the body of a macro expansion function, or might be the body of
an EVAL-WHEN COMPILE, or might be an interpreted function called from
one of those places), and a macro invocation in that interpreted code is
expanded, the environment argument to the expander function contains
information that indicates that the macro expansion will be used in the
compile-time environment, not in the run-time environment.
Terminology: The compile-time environment is the Lisp in which the
function COMPILE-FILE was called. The run-time environment is the
Lisp(s) in which the LOAD function will be called to load the file
output by COMPILE-FILE.
Test Cases/Examples:
A test case cannot be written without using CLOS meta objects or other
extensions to Common Lisp. Here is an example:
(defmacro defclass (name ... &environment e)
`(setf (find-class ',name ',e) ...))
Rationale:
CLOS requires this.
Current practice:
Something resembling this already exists in almost all Common Lisp
implementations for internal use by the compiler. Symbolics Genera
currently uses a special variable instead of the macro expansion
environment, which of course is wrong and produces incorrect
behavior in some cases. I don't know about other implementations.
Cost to Implementors:
The cost of including the information in the environment argument to an
expander function is probably trivial, unless the representation of
macro expansion environments is completely non-extensible. The main
cost is making sure that the information is propagated from
COMPILE-FILE, through the compiler, to all places where the compiler
calls MACROEXPAND or MACROEXPAND-1.
Cost to Users:
None.
Cost of non-adoption:
The proposal was already adopted in June, this is just a clarification
of what it entails.
Benefits:
This clarification should save a few implementors some false steps.
Esthetics:
Common Lisp's existing concept of environment seems like the right
mechanism to say things about environments.
Discussion:
The CLOS meta-object facility is probably going to need an addition to
the language, to make SYMBOL-FUNCTION support the environment argument
in the same way that FIND-CLASS and ENSURE-GENERIC-FUNCTION do. However,
since I'm not sure if that's needed, and since that would be an addition
rather than a clarification, I'll ignore it for the moment. Similarly,
it would be a useful to have a predicate that can be applied to a macro
expansion environment and tells you whether it refers to the run-time
environment or the compile-time environment. I'm not proposing that now.
The terms "run-time" and "compile-time" are somewhat confusing. Perhaps
better terms, such as the "deferred environment" and the "immediate
environment" or the "future environment" and the "present environemnt"
could be adopted. In this proposal I have used the terms that became
official when X3J13 voted for 88-002R.
∂21-Sep-88 1138 CL-Cleanup-mailer Re: message references
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 11:37:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 11:33:29 PDT
From: masinter.PA@Xerox.COM
Date: 21 Sep 88 11:28:20 PDT
Subject: Re: message references
In-reply-to: jonl@lucid.com's message of Wed, 21 Sep 88 11:24:20 PDT,
<8809211824.AA01379@bhopal>
To: Jon L White <jonl@lucid.com>
cc: masinter.PA@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <880921-113329-1210@Xerox>
Sorry, yes, I misunderstood. I wouldn't like the "References" section of cleanup
proposals to have something that wasn't generally available available to readers
who don't have access to the EMail archives.
∂21-Sep-88 1153 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 11:53:28 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463370; Wed 21-Sep-88 14:50:44 EDT
Date: Wed, 21 Sep 88 14:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Gregor.pa@Xerox.COM,
Patrick Dussud <dussud@lucid.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Eric Benson <eb@lucid.com>
cc: CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <880608165454.0.KMP@PEWEE.SCRC.Symbolics.COM>,
<19880921012425.2.GREGOR@PORTNOY.parc.xerox.com>,
<8809210256.AA19086@rainbow-warrior>,
<8809210424.AA00814@defun.utah.edu>,
<8809210622.AA01147@blacksox>
Message-ID: <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
For the purposes of discussion, here's a copy of KMP's last writeup
stripped down to just what I personally think are the essentials.
I don't mean to supersede Kent's writeup, just to give people
something short enough to read. Kent's writeup also included
the new-special-form version and compared and constrasted the
two versions.
Issue: LOAD-TIME-EVAL
References: #, (p. 356), (EVAL-WHEN (LOAD) ...) (p. 69-70)
Category: ADDITION
Edit history: 06-Jun-87, Version 1 by James Kempf
17-Jul-87, Version 2 by James Kempf
12-Nov-87, Version 3 by Pitman (alternate direction)
01-Feb-88, Version 4 by Moon
(from version 2 w/ edits suggested by Masinter)
06-Jun-88, Version 5 by Pitman
(fairly major overhaul, merging versions 3 and 4)
21-Sep-88, Version 6 by Moon (stripped down)
Status: For internal discussion
Problem description:
Common Lisp provides reader syntax (#,) which allows the programmer
to designate that a particular expression within a program is to be
evaluated early (at load time) but to later be treated as a constant.
Unfortunately, no access to this capability is available to programs
which construct other programs without going through the reader.
Some computations can be deferred until load time by use of EVAL-WHEN,
but since EVAL-WHEN must occur only at toplevel, and since the nesting
behavior of EVAL-WHEN is quite unintuitive, EVAL-WHEN is not a general
solution to the problem of load-time computation of program constants.
Also, CLtL is vague about the meaning of #,exp as a form (rather than
inside a quoted constant).
Proposal (LOAD-TIME-EVAL:QUOTED-MAGIC-TOKEN):
Add a function MAKE-LOAD-TIME-CONSTANT, as described here:
MAKE-LOAD-TIME-CONSTANT form env [Function]
FORM is a Lisp form. ENV is an environment of the sort received
by the &ENVIRONMENT argument to a macro.
When MAKE-LOAD-TIME-CONSTANT is called from the interpreter or the
COMPILE function, it simply evaluates FORM in the null lexical
environment and returns its value. When MAKE-LOAD-TIME-CONSTANT is
called during a file compilation, the result is a special object
that is recognized at load time, when it occurs inside a constant.
At load time, FORM is evaluated and its value is substituted for
the object.
MAKE-LOAD-TIME-CONSTANT uses its ENV argument to determine whether it
is being called during a file compilation.
Specify that '(... #,exp ...) is equivalent to
'(... #.(MAKE-LOAD-TIME-CONSTANT 'exp env) ...)
with the "right" value of env.
Specify that anything Common Lisp says about destructive operations
on constants also applies to values returned by forms used as
arguments to MAKE-LOAD-TIME-CONSTANT.
Clarify that #,exp as a form is an error and that load-time constants
can only be used inside the QUOTE special form.
Rationale:
This approach is the most compatible with existing practice.
Cost to Implementors:
The cost to implementors will depend on how #, is implemented.
In some implementations, the primitives for implementing
MAKE-LOAD-TIME-CONSTANT may already exist, in others, more substantial
changes may be required.
Cost to Users:
This change is upward compatible with user code.
Benefits:
It would be possible for macros to expand into load time constants.
Example:
;; This is a stripped down version of something from CLOS
(defmacro deffoo (name attribute &environment e)
`(defun ,name (x)
(aref x (aref ',(make-load-time-constant
`(get-table-for ',attribute)
e)
',(get-index-for ',attribute)))))
Current practice:
Although most implementations provide a substrate which would allow
program-mediated access to load time evaluation in some way, the language
only defines access to this substrate through the sharpsign read syntax.
∂21-Sep-88 1300 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:00:38 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463431; Wed 21-Sep-88 15:58:16 EDT
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM,
dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com,
CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Well, let me say up front that this description is absolutely unacceptable
to me because of the verbiage about destructive modification.
Also, I am concerned about how the "right thing" can be done with the
env argument in the case of
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) '(X #,(SQRT 3))))
In a file compiler, the #, must read in a way that is acceptable to the
compiler's runtime environment (compile to core) and the compiler's file
environment (compile to file). And this decision must be made at
readtime.
If instead you wrote:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) #,`(X ,(SQRT 3))))
and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
core operation could treat the LOAD-TIME-VALUE special form in one way
and the file compiler could treat the LOAD-TIME-VALUE special form
another way and things would work nicely as a natural result of the
accessibility of the lexical environment from the special form.
∂21-Sep-88 1302 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:02:27 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05757g; Wed, 21 Sep 88 12:00:43 PST
Received: by blacksox id AA01195g; Wed, 21 Sep 88 12:58:25 pdt
Date: Wed, 21 Sep 88 12:58:25 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809211958.AA01195@blacksox>
To: piazza%lisp.DEC@decwrl.dec.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jeffrey Piazza's message of 21 Sep 88 13:55 <8809211757.AA24142@decwrl.dec.com>
Subject: SYMBOL-MACROLET-SEMANTICS (Version 2)
Shouldn't SETQ of a symbol macro be permitted, and defined to be the
same as SETF?
You should clarify the statement that ``recursive'' symbol macros are
an error. Certainly it is legal for one symbol macro to expand into
another, or for a symbol macro to expand into a regular macro call
which expands into a (different) symbol macro. Perhaps
``self-recursive'' would be better.
Should there be a global version of SYMBOL-MACROLET, i.e.
DEFINE-SYMBOL-MACRO?
∂21-Sep-88 1321 CL-Compiler-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:21:33 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05781g; Wed, 21 Sep 88 12:18:41 PST
Received: by blacksox id AA01201g; Wed, 21 Sep 88 13:16:24 pdt
Date: Wed, 21 Sep 88 13:16:24 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809212016.AA01201@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM,
sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU,
cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 21 Sep 88 15:58 EDT <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Also, I am concerned about how the "right thing" can be done with the
env argument in the case of
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) '(X #,(SQRT 3))))
In a file compiler, the #, must read in a way that is acceptable to the
compiler's runtime environment (compile to core) and the compiler's file
environment (compile to file). And this decision must be made at
readtime.
If instead you wrote:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) #,`(X ,(SQRT 3))))
and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
core operation could treat the LOAD-TIME-VALUE special form in one way
and the file compiler could treat the LOAD-TIME-VALUE special form
another way and things would work nicely as a natural result of the
accessibility of the lexical environment from the special form.
This should work:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
`(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
(DEFUN FOO (X) (LIST-FOR-FOO)))
∂21-Sep-88 1329 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:28:54 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 463467; 21 Sep 88 16:26:11 EDT
Date: Wed, 21 Sep 88 16:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, Gregor.pa@Xerox.COM,
dussud@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu,
CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <8809212016.AA01201@blacksox>
Message-ID: <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 21 Sep 88 13:16:24 pdt
From: Eric Benson <eb@lucid.com>
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Also, I am concerned about how the "right thing" can be done with the
env argument in the case of
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) '(X #,(SQRT 3))))
... This should work:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
`(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
(DEFUN FOO (X) (LIST-FOR-FOO)))
I'm not concerned that there is no way to get the right thing, I'm
concerned that the DWIM alluded to in Moon's stripped down proposal
is not possible to really guarantee. I'm concerned that if #, is
described as just "doing the right thing" environment-wise, then
it will lose randomly because that can't always be satisfied. Then
people will think of it as something yucky to be avoided rather than
something clean and graceful. [Btw, this is a case that was only
recently shown to me -- not something I knew when I wrote the
predecessor to his proposal.]
If instead LOAD-TIME-VALUE were a special form and #, could expand
into it (outside of QUOTE), there would be no such yuckiness for
people to get burnt by, so #, would not have to become something
that people avoided out of paranoia because they didn't understand it.
∂21-Sep-88 1340 CL-Compiler-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 13:40:08 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05821g; Wed, 21 Sep 88 12:37:17 PST
Received: by blacksox id AA01222g; Wed, 21 Sep 88 13:34:57 pdt
Date: Wed, 21 Sep 88 13:34:57 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809212034.AA01222@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
Gregor.pa@Xerox.COM, dussud@STONY-BROOK.SCRC.Symbolics.COM,
sandra%defun@cs.utah.edu, CL-Cleanup@SAIL.STANFORD.EDU,
cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 21 Sep 88 16:25 EDT <880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
By the way, I forgot a ' in that example. Here's the fixed version:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFMACRO LIST-FOR-FOO (&ENVIRONMENT ENV)
`'(X ,(MAKE-LOAD-TIME-CONSTANT '(SQRT 3) ENV)))
(DEFUN FOO (X) (LIST-FOR-FOO)))
∂21-Sep-88 1403 CL-Cleanup-mailer Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:03:34 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00522; Wed, 21 Sep 88 17:03:06 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA12637; Wed, 21 Sep 88 16:35:37 EDT
Message-Id: <8809212035.AA12637@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: PRINT-PRETTY-HOOK (version 1)
Date: Wed, 21 Sep 88 16:35:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
This is a bit late for a minor change. But it looks like the
following will make my, and many others, lives much easier in the
future.
---------------
Issue: PRINT-PRETTY-HOOK
References: *PRINT-PRETTY* p. 371, WRITE, PRINT, PPRINT, etc. pp. 382-383,
FORMAT pp. 385-407
Category: CHANGE, ADDITION
Edit history: Version 1 by Pierson, 9/21/88
Status: For Internal Discussion
Problem description:
Pretty printers are a part of the Common Lisp development environment
that are relatively easy for users to write themselves. Furthermore,
vendor supplied pretty printers vary widely in quality.
Unfortunately, while it is easy for a user to write a pretty printer,
many other Common Lisp functions are defined to invoke the pretty
printer internally under control of the variable, *PRINT-PRETTY*.
Proposal (PRINT-PRETTY-HOOK:USE-VALUE):
Specify that if the value of *PRINT-PRETTY* is of type FUNCTION that
the function will be called with the standard arguments of PPRINT
whenever the pretty printer is to be invoked.
Test Cases/Examples:
(SETQ *PRINT-PRETTY* NIL) (PRINT FOO)
Will print the value of FOO without extra white space.
(SETQ *PRINT-PRETTY* T) (PRINT FOO)
Will print the value of FOO using the standard pretty printer.
(DEFUN MY-PPRINT (OBJECT &OPTIONAL OUTPUT-STREAM) ...)
(SETQ *PRINT-PRETTY* #'MY-PPRINT) (PRINT FOO)
(SETQ *PRINT-PRETTY* 'MY-PPRINT) (PRINT FOO)
Will both print the value of FOO using a special pretty printer.
Rationale:
This seems like the simplest portable method of allowing a user to
install a custom pretty printer.
Current practice:
I know of no Common Lisp implementation that supports this feature
(though it's not specifically forbidden by CLtL).
Cost to Implementors:
An additional funcall will have to be added everywhere the value of
*PRINT-PRETTY* is checked. This should be fairly localized in most
implementations.
Cost to Users:
None, this is an upward-compatible change.
Cost of non-Adoption:
Users will continue to be stuck with the vendor-supplied pretty
printer in many cases.
Benefits:
Users will be able to modify this part of the programming environment
to suite their tastes. In addition, users of extendable pretty
printers will be able to ensure that their extensions are portably
available in all Common Lisp environments.
Aesthetics:
This sort of hook could well be considered an additional wart on the
language.
Discussion:
This proposal was inspired by Dick Water's announcement of a
forthcoming portable Common Lisp pretty printer.
Like editors, pretty printers tend to be very much a matter of taste.
Since the language defines several ways that the pretty printer gets
invoked, the user should have control over which pretty printer is
used across as many of these ways as possible.
∂21-Sep-88 1408 CL-Compiler-mailer Re: Issue: LOAD-TIME-EVAL (Version 6)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:08:10 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA08853; Wed, 21 Sep 88 15:05:39 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA01411; Wed, 21 Sep 88 15:05:29 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809212105.AA01411@defun.utah.edu>
Date: Wed, 21 Sep 88 15:05:28 MDT
Subject: Re: Issue: LOAD-TIME-EVAL (Version 6)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>, Gregor.pa@xerox.com,
Patrick Dussud <dussud@lucid.com>,
Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Eric Benson <eb@lucid.com>, CL-Cleanup@sail.stanford.edu,
cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Sep 88 14:50 EDT
I have two problems with this proposal. The first is a big one: there
a more situations in which code is processed than simply
interpretation and compilation. It is not an either/or situation. A
person here at the UofU, for example, has been working on a portable
type inference preprocessor. It reads in code, decorates it with lots
of type declarations, and writes it out to another file which may then
either be loaded interpretively or compiled with COMPILE-FILE. Under
this proposal, such a tool would essentially have to redefine
MAKE-LOAD-TIME-CONSTANT (a no-no) to always force evaluation to be
delayed, i.e.
(defun make-load-time-constant (form env)
`(make-load-time-constant ',form ',env))
That's why I believe that providing this functionality by defining it
as a special form is a superior alternative.
The other quibble is with the environment argument. As I've already
pointed out to Moon, the environment object returned by &ENVIRONMENT,
as currently defined, may return an incomplete environment that
contains information only about MACROLET constructs in the surrounding
lexical environment. I gather that this proposal depends on
&ENVIRONMENT being redefined to include information about whether or
not compilation is in progress, and that would be the only part of the
environment object that is used by MAKE-LOAD-TIME-CONSTANT, right? (I
also understand that CLOS depends on maintaining some other
information in environment objects so I think a proposal to clarify
what they must really contain is in order.)
All things considered, I could live with this proposal, since it would
certainly not be any worse than the status quo. On the other hand, I
would definitely prefer to either remove #, entirely or provide the
functionality as a special form.
-Sandra
-------
∂21-Sep-88 1436 CL-Cleanup-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 14:36:31 PDT
Received: by ti.com id AA04913; Wed, 21 Sep 88 16:33:40 CDT
Received: from Kelvin by tilde id AA03344; Wed, 21 Sep 88 16:17:59 CDT
Message-Id: <2799868740-14879380@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 21 Sep 88 16:19:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
In-Reply-To: Msg of Wed, 21 Sep 88 13:48 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> No, of course not. I'm saying that #, is a feature of the reader that
> needs to cause the loader to do something appropriate with it. #, never
> affects the evaluator, EVAL and COMPILE never see anything different when
> #, is used than they would see normally.
I was forgetting that in the old scenario, in evaluated code, the
expression following #, is executed by the reader instead of the
evaluator. I guess the basic issue is: if you generate one of these
load-time values in a macro expansion within the evaluator, should
the expression get evaluated as part of the macro expansion, or should
it be done directly by the evaluator? Certainly tying the evaluation to
the macro expansion simplifies things greatly since the question of how
many times it gets evaluated is the same as the question of how many
times the macro gets expanded. Maybe we could get the best of both
proposals by saying that LOAD-TIME-VALUE is a macro instead of a special
form, and it is defined something like this:
(DEFMACRO LOAD-TIME-VALUE (EXP)
(IF (compiling-p)
`(some-special-thing-only-the-compiler-cares-about ',EXP)
`(QUOTE ,(EVAL EXP))))
As for the assumption that a QUOTE form containing a "magic cookie" passes
through the compiler just like any other QUOTE form, that unfortunately is
not quite true. In our implementation the compiler actually has to scan
QUOTE forms looking to see if it contains a "magic cookie" for two
reasons: to suppress optimizations based on the value of the constant,
and to prevent merging EQUAL forms that use load-time evaluation. That's
why I think this approach is ugly -- it uses the syntax of a constant for
something that isn't really a constant.
∂21-Sep-88 1525 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Sep 88 15:25:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463583; Wed 21-Sep-88 18:22:36 EDT
Date: Wed, 21 Sep 88 18:22 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Gray@DSG.csc.ti.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Compiler@SAIL.STANFORD.EDU,
CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2799868740-14879380@Kelvin>
Message-ID: <880921182223.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 21 Sep 88 16:19:00 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
...
(DEFMACRO LOAD-TIME-VALUE (EXP)
(IF (compiling-p)
`(some-special-thing-only-the-compiler-cares-about ',EXP)
`(QUOTE ,(EVAL EXP))))
...
This still makes the programmer's intent opaque to code analysis tools.
I insist that there is nothing odd about a LOAD-TIME-VALUE expression
and that code walkers should be able to expect it and do reasonable
things with it.
For example, I once got a warning from a compiler about something like:
(* (THE FLOAT '#,(SQRT PI)) ...)
because '(#:MAGIC-MARKER SQRT PI) was a quoted value (and hence subject
to compiler scrutiny) and the constant was not a FLOAT. This was obviously
just a bug because the compiler should expect whatever magic it uses
internally to make #, work, but it can happen to users, too.
If the special thing that only the compiler knows about is going to be
the result of
(MACROEXPAND '(LOAD-TIME-VALUE (SQRT PI))
then I cannot trivially write code-analysis tools which will be able to
call MACROEXPAND and say of the result: "Oh, this is a value that will
not be known until runtime. I can (a) defer further analysis to runtime,
or (b) try to infer things about what the result of a SQRT call might
be, or ... (*) give up knowing I did the best I could."
Instead it will say ``Gosh, here is a special form I never heard of''
or ``Gosh, here's an undefined function I should warn the user about''
or whatever.
There is no reason for every implementation to use a gratuitously
different marker, or a gratuitously different convention about whether
it's (marker . form) or (marker form). We might as well document that
LIST is how it's composed and we might as well make a standard variable
that holds the marker because it can only improve portability to do so
and because there is no runtime overhead in not doing so. But then we'd
be doing
(EQ (CAR FORM) COMPILER:*SHARP-COMMA-MARKER*)
rather than
(EQ (CAR FORM) 'LOAD-TIME-VALUE)
and I don't see the point. It's not like either of them is genuinely
inaccessible so it could still get into places you didn't want it.
Better to just define the marker (an interned symbol comes to mind),
define places where it makes sense (the car of a form in a
for-evaluation position comes to mind) -- in effect, to define it to
be the special form that it obviously is. We keep using the word "magic"
-- all other magic in the language is accomplished by special forms.
Let's just be uniform and call this a special form, too.
∂21-Sep-88 1718 CL-Cleanup-mailer Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 21 Sep 88 17:18:04 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA06107g; Wed, 21 Sep 88 16:15:57 PST
Received: by bhopal id AA03021g; Wed, 21 Sep 88 17:15:24 PDT
Date: Wed, 21 Sep 88 17:15:24 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809220015.AA03021@bhopal>
To: pierson%mist@multimax.ARPA
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Tue, 13 Sep 88 18:00:34 EDT <8809132200.AA01990@mist.UUCP>
Subject: Issue: REQUIRE-PATHNAME-DEFAULTS (version 1)
I support this proposal. It's definitely the most positive step short
of flushing REQUIRE that can be taken with the modules mess.
Note that I'm not in favor of flushing REQUIRE/PROVIDE simply because
they don't meet the overexpectations outlined below. Rather, given
the acceptance of your proposal, they would play the limited role of
a "safety net" underneath the currently-vendor-specific DEFSYSTEM
facilities, and they would be fully portable in that role.
In particular, there are many persons in the community who confuse the
PROVIDE/REQUIRE pair with some limited sort of DEFSYSTEM. This is a
major mistake. Symbolics provides it's own propietary DEFSYSTEM with
it's product; and Lucid is providing a similar sort of thing with it's
release 3.0 (LUMEN). However, I don't believe we are currently in a
position to discuss standardizing a more complete, portable module
dependency and system building facility (via ordered file compiling,
loading, etc.).
In the meantime, your proposal should cut out the wart on REQUIRE that
tempts so many to treat it as some kind of cheap replacement for a
DEFSYSTEM. That is, a REQUIRE statement should not be viewed as
expressing merely a "latent" dependency of one module upon another, but
rather as a way of saying "do not proceed until this facility is fully
available". This is especially useful when loading files, since
irreparable damage can be done *** merely by reading in a file *** if the
packages which the current package inherits from are not fully "set up".
Also, there is often a tendency to confuse package and modules; as
defined in CLtL, the only clear course is to treat them as orthogonal
facilities that intersect only in so far as the initialization of a
package layout may be performed by a REQUIRED module.
In fact, a *very* reasonable scenario is to have several modules all "in"
the same package, and the specify, in whatever implementation-dependent
way one can, that the very first file/module to be loaded is the one
that creates all the packages needed by the subsystem. If this package
creator file is a module all by itself, then a REQUIRE for it from other
files isn't so much an attempt to lazyily create the needed packages,
but simply to ensure that the other files will not be loaded before the
requisite packages are fully set up. It is in this role that REQUIRE can
be most useful -- in giving an early error signal when something is being
done out of order, rather than the late signal raised by "name conflicts".
. . .
Another facet of "module" often overlooked is that it is an abstract
notion that need not be co-incident with a file. You could just as
easily "provide" the facilities encompassed in the module by compiling
"in core", by SETQ'ing, and so on, as you can by loading in some specific
named file. [Indeed, this kind of dynamic is Lisp's beauty over the
"conventional" programming languages]. The PROVIDE function is merely
the announcement that the "facility" is available. Of course, it goes
without saying that one may call REQUIRE from places other than the
toplevel forms of a file.
Consequently ,I take it as obvious that a module which is contained in a
file (i.e., it is "provided" by loading the file) cannot truly be said to
be "provided" until the whole file is loaded in. In such a case, it
means putting the PROVIDE statement at the end of a file, as you suggest.
At least one vendor I know of recommends putting the PROVIDE first, and
has buggered its LOAD function to notice these top-level calls and to
call UNPROVIDE if the file loading is aborted. The flaw in this is that
during the dynamic interval of loading, the value of *MODULES* is "lying"
in that the remaining portions are not in fact available. Similarly,
if a file is aborted after being half loaded (and the module is unprovided)
then *MODULES* will still be lying, since the earlier facilities indeed
have been "provided".
About the only excuse I've heard for requesting this behaviour (the "lying"
PROVIDE) is that one wants to have two mutually-dependent files, but not
to specify that one must be loaded first before the other one is loaded.
Quickly, you see the long arm of the "cheap shot" DEFSYSTEM intruding again.
-- JonL --
P.S. This note was delayed due to a mail system gaff. However, looking
ahead into the mails, I see that you were already proposing to
accommodate the mututally-requiring files by suggesting the LOAD
time "back out" of an early PROVIDE. I hope the above comments can
provide some a basis for agreeing not bugger LOAD this way after all.
∂21-Sep-88 2329 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 21 Sep 88 23:28:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 21 SEP 88 23:26:53 PDT
Date: 21 Sep 88 23:27 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-reply-to: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of Wed,
21 Sep 88 16:35:32 EDT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880921-232653-1366@Xerox>
I thought at one time that extensions to prettyprint were going to be handled as
specializations to a standard generic function in the same way that print-object
is specializable. I'd like at least to make sure that this is present.
There's too much that the prettyprinter needs to do "right" that a portable
prettyprinter can't do, that I wonder if this really solves the problem. That is
"while it is easy for a user to write a pretty printer" is it really easy for a
user to write a correct pretty printer? One that can deal with *print-circle*,
for example?
∂22-Sep-88 0728 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 22 Sep 88 07:27:55 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA06543; Thu, 22 Sep 88 10:27:31 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA13532; Thu, 22 Sep 88 10:29:12 EDT
Message-Id: <8809221429.AA13532@mist.UUCP>
To: Patrick Dussud <dussud%lucid.com@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of Wed, 21 Sep 88 19:51:50 -0700.
Date: Thu, 22 Sep 88 10:29:09 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Would it help if the pretty print function took an additional optional
argument, the current print level (the current print length always
starts at 0 when the function is called.)
∂22-Sep-88 0741 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA by SAIL.Stanford.EDU with TCP; 22 Sep 88 07:40:54 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA06691; Thu, 22 Sep 88 10:40:34 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA13567; Thu, 22 Sep 88 10:42:15 EDT
Message-Id: <8809221442.AA13567@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of 21 Sep 88 23:27:00 -0700.
Date: Thu, 22 Sep 88 10:42:09 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I thought at one time that extensions to prettyprint were going to be
handled as specializations to a standard generic function in the same
way that print-object is specializable. I'd like at least to make sure
that this is present.
I very much want this to be present, but it's inadequate for two reasons:
1 CLOS may not be a required part of Common Lisp, therefore portable code
may not be able to assume it.
2 Writing a separate pretty printer for each structure using standard
Common Lisp functions is likely to be much more verbose than doing
the same job using one of Dick Water's pretty printers. Of course
some people will find the extension syntax of Dick's pretty
printers distasteful, but I'm proposing to standardize on them.
There's too much that the prettyprinter needs to do "right" that a
portable prettyprinter can't do, that I wonder if this really solves
the problem. That is "while it is easy for a user to write a pretty
printer" is it really easy for a user to write a correct pretty
printer? One that can deal with *print-circle*, for example?
There may be things that a user written pretty printer can't do right
(though I can't think of any) but *PRINT-CIRCLE* support certainly
isn't one of them as long as the pretty printer starts at the top
(i.e. changing from one printer to another at say, level 3, will break
circular printing for any two independent print functions). I put
full *PRINT-CIRCLE* support into the VAX Lisp version of GPRINT; doing
it as efficiently as possible was a bit of work, but it didn't require
any non user visible support (printing things like structures did
require implementation dependent functions, but that's being addressed
by a separate proposal). Remember that the pretty printer can always
punt to PRINx-TO-STRING for atoms it doesn't understand.
∂22-Sep-88 0814 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 22 Sep 88 08:14:08 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 22 Sep 88 11:11:01 EDT
To: cl-cleanup@sail.stanford.edu
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-reply-to: Your message of Thu, 22 Sep 88 10:42:09 -0400.
<8809221442.AA13567@mist.UUCP>
Date: Thu, 22 Sep 88 11:10:52 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
1 CLOS may not be a required part of Common Lisp, therefore portable code
may not be able to assume it.
Do others share this view? My understanding of recent decisions was that
CLOS was going to be in the standard with the same status as CONS and EVAL
-- required of any system that wants to call itself a legal Common Lisp.
I guess there's still some question about the meta-object stuff, but can't
we assume the rest?
-- Scott
∂22-Sep-88 0852 CL-Cleanup-mailer Re: Issue: FUNCTION-DECLARATION (version 1)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 08:52:38 PDT
Received: by ti.com id AA11218; Thu, 22 Sep 88 10:49:02 CDT
Received: from Kelvin by tilde id AA16573; Thu, 22 Sep 88 10:33:10 CDT
Message-Id: <2799934457-2312675@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 22 Sep 88 10:34:17 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: vanroggen%aitg.DEC@DECWRL.DEC.COM
Cc: cl-cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-DECLARATION (version 1)
In-Reply-To: Msg of Wed, 21 Sep 88 10:34:34 PDT from vanroggen%aitg.DEC@DECWRL.DEC.COM
> CLtL permits ambiguous FUNCTION declarations. One can say
> (DECLARE (FUNCTION F (VECTOR INTEGER) T))
> to indicate that the function binding for F is of a certain type. Yet
> one can also say
> (DECLARE (FUNCTION X Y Z))
> to indicate that the variables X, Y, and Z have values which are functions.
Well, that depends on how you read it. I always assumed that it was just
an oversight that page 158 doesn't mention that FUNCTION is an exception
to the list in table 4-1 since the next page gives it a different meaning.
Are there any implementations that actually try to support it both ways?
Actually, now that I think about it, both forms could be supported since
there isn't really any ambiguity -- in one case the third element of the
declaration specifier must be a list and in the other it must be a non-nil
symbol if present.
> Proposal (FUNCTION-DECLARATION:DELETE)
>
> The declaration (FUNCTION name argtypes valtypes) is no longer permitted
> to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
>
> The declaration (FUNCTION var1 var2) would just be an abbreviation for
> (TYPE FUNCTION var1 var2).
Maybe this would have been cleaner, but I don't see sufficient
justification for making an incompatible change now.
> Current Practice:
>
> VAX LISP treats FUNCTION declarations as describing only function bindings.
I'm not quite sure which you mean; do you mean it only supports the
(FUNCTION name argtypes valtypes) form? The Explorer only supports this
one.
> Cost to Users:
>
> Existing uses of the FUNCTION declaration for function bindings will need
> to be changed to FTYPE declarations. Such code could not have been portable,
> though.
That last sentence is not true, since CLtL clearly says that it is allowed
and defines what it means, so no valid implementation can disallow it.
∂22-Sep-88 0932 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88 09:32:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463973; Thu 22-Sep-88 12:30:37 EDT
Date: Thu, 22 Sep 88 12:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
To: masinter.pa@Xerox.COM
cc: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>, cl-cleanup@sail.stanford.edu
In-Reply-To: <880921-232653-1366@Xerox>
Message-ID: <19880922163031.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 88 23:27 PDT
From: masinter.pa@Xerox.COM
I thought at one time that extensions to prettyprint were going to be handled as
specializations to a standard generic function in the same way that print-object
is specializable.
If you read the writeup of print-object (88-002R p.2-67) you'll see that the
pretty printer is required to call the print-object generic function, just as
the ugly printer does. Perhaps this wasn't said clearly enough.
As Pierson pointed out, this form of extension to the printer is orthogonal
to he wants to do. I haven't figured out whether what he really wants is to
be allowed to redefine the unnamed function that WRITE, PRINT, PRINC, FORMAT,
etc. all call, or whether he wants to be able to redefine the unnamed function
that the read-eval-print loop calls to print things. Either way, the
desire is for a standardized way to redefine a system function wholesale,
not to make it generic on its arguments. This seems like a reasonable idea,
although there is likely to be a surprising number of implementation-dependent
difficulties.
Using the value of *PRINT-PRETTY* to enable a user-defined pretty printer is
incompatible with Symbolics' current practice, where the value of *PRINT-PRETTY*
tells the pretty printer additional information about the value being printed,
for instance whether it is a program or data. This should be orthogonal to
the choice of which pretty printer to use. This pretty printer was written
by Dick Waters, so perhaps his current portable pretty printer uses the same
technique.
∂22-Sep-88 0932 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 22 Sep 88 09:32:30 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00508; Thu, 22 Sep 88 11:47:18 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA13717; Thu, 22 Sep 88 11:48:59 EDT
Message-Id: <8809221548.AA13717@mist.UUCP>
To: Scott.Fahlman%B.GP.CS.CMU.EDU@Multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of Thu, 22 Sep 88 11:10:52 -0400.
<8809221523.AA00252@multimax.ARPA>
Date: Thu, 22 Sep 88 11:48:57 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
1 CLOS may not be a required part of Common Lisp, therefore portable
code may not be able to assume it.
Do others share this view? My understanding of recent decisions was that
CLOS was going to be in the standard with the same status as CONS and EVAL
-- required of any system that wants to call itself a legal Common Lisp.
I guess there's still some question about the meta-object stuff, but can't
we assume the rest?
As I understand the vote at the last meeting, we voted to make CLOS
chapters 1 and 2 the official definition of that part of the Common
Lisp Object System but there was a clear understanding that we would
decide later whether all Common Lisp implementations were required to
support an object system at all.
Personally I think that making CLOS optional would be a lousy idea,
but there does seem to be enough sentiment for it that we can't assume
that it won't happen. Am I all wet here?
∂22-Sep-88 0941 CL-Cleanup-mailer Issue: LOAD-TIME-EVAL (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88 09:41:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463981; Thu 22-Sep-88 12:37:15 EDT
Date: Thu, 22 Sep 88 12:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LOAD-TIME-EVAL (Version 6)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Gregor.pa@Xerox.COM, dussud@lucid.com, sandra%defun@cs.utah.edu, eb@lucid.com,
CL-Cleanup@SAIL.STANFORD.EDU, cl-compiler@sail.stanford.edu
In-Reply-To: <880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880922163716.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Wed, 21 Sep 88 15:58 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Well, let me say up front that this description is absolutely unacceptable
to me because of the verbiage about destructive modification.
Also, I am concerned about how the "right thing" can be done with the
env argument in the case of
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) '(X #,(SQRT 3))))
In a file compiler, the #, must read in a way that is acceptable to the
compiler's runtime environment (compile to core) and the compiler's file
environment (compile to file). And this decision must be made at
readtime.
Of course this doesn't work and has never worked.
If instead you wrote:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) #,`(X ,(SQRT 3))))
and #, expanded into a LOAD-TIME-VALUE expression, then the compile to
core operation could treat the LOAD-TIME-VALUE special form in one way
and the file compiler could treat the LOAD-TIME-VALUE special form
another way and things would work nicely as a natural result of the
accessibility of the lexical environment from the special form.
You should be more explicit that what you are actually arguing for is
the removal of #, from the language. You're also proposing to add a
new feature with very complicated but useful semantics, LOAD-TIME-VALUE,
to the language. Pretending that you're fixing #, only obscures the issues.
∂22-Sep-88 0946 CL-Compiler-mailer Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88 09:45:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 463987; Thu 22-Sep-88 12:41:59 EDT
Date: Thu, 22 Sep 88 12:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Eric Benson <eb@lucid.com>,
Sandra J Loosemore <sandra%defun@cs.utah.edu>, David N Gray <Gray@DSG.csc.ti.com>
cc: Gregor.pa@Xerox.COM, Patrick Dussud <dussud@lucid.com>, CL-Compiler@SAIL.Stanford.EDU,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880921142327.2.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>,
<19880921185047.9.MOON@EUPHRATES.SCRC.Symbolics.COM>,
<880921155806.5.KMP@GRYPHON.SCRC.Symbolics.COM>,
<8809212016.AA01201@blacksox>,
<880921162559.7.KMP@GRYPHON.SCRC.Symbolics.COM>,
<8809212034.AA01222@blacksox>,
<8809212105.AA01411@defun.utah.edu>,
<2799868740-14879380@Kelvin>,
<880921182223.8.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880922164200.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I will have nothing further to say on this issue.
∂22-Sep-88 1007 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88 10:07:24 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 464007; Thu 22-Sep-88 13:06:00 EDT
Date: Thu, 22 Sep 88 13:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 2)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <19880922170548.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
Category: ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Problem description:
Most people interpret CLtL's phrase "(TYPE type var1 var2 ...) affects
only variable bindings" to mean that code such as the following is
not valid Common Lisp, because a type declaration can only be attached
to a binding, not used free.
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable to
be not a member of the declared type, within the scope of the
declaration. Clarify that this makes the above program a valid program
and that this kind of declaration means the same thing as inserting
THE in every reference to the variable and every setq of the variable.
Clarify that if nested type declarations refer to the same variable,
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
There is no reason to forbid this usage, and people have often asked
for it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already, with a warning that
it is an extension to Common Lisp.
Cost to Implementors:
None, it is valid to ignore type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
The above example will not have to be written in the following silly way,
which only works if x and y are used read-only:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(let ((x x) (y y))
(declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Esthetics:
This provides a clean and simple way for the programmer to express what
she knows about the values a variable may take on within a certain
region of the program. Different compilers will use this information in
different ways; it's most aesthetic for the portable language to be free
of assumptions about how the compiler will use this information.
Discussion:
None.
∂22-Sep-88 1015 CL-Cleanup-mailer SYMBOL-MACROLET-SEMANTICS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Sep 88 10:15:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 464013; Thu 22-Sep-88 13:13:40 EDT
Date: Thu, 22 Sep 88 13:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET-SEMANTICS (Version 2)
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809211757.AA24142@decwrl.dec.com>
Message-ID: <19880922171345.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM, with a couple
of important reservations, which are basically the same as Eric
Benson's comments:
SETQ of a symbol macro must be allowed. The reason given for removing
it is wrong -- SETQ of symbol macros was allowed in order to avoid
making any distinction between symbol macros and variables, which is
the only reason symbol macros are used by CLOS at all.
The comment about "recursive symbol macros" doesn't make any sense to
me. I don't think it would hurt the proposal to take it out. Saying
that expansions of symbol macros are subject to further expansion in
the same lexical environment as the symbol macro invocation, exactly
analogous to normal macros, is sufficient. If and when Common Lisp
is changed to provide more careful control over the lexical environment
of macro expansions, the same mechanism should work for both normal
macros and symbol macros.
∂22-Sep-88 1041 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 3
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 10:41:31 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27264; Thu, 22 Sep 88 10:40:03 PDT
Date: Thu, 22 Sep 88 10:40:03 PDT
Message-Id: <8809221740.AA27264@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: Issue SYMBOL-MACROLET-SEMANTICS, Version 3
Status: For Internal Discussion
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Finally, the rule that SETQ of a symbol macro must be treated as a SETF of
the expansion seems to be a kludge which was introduced only to support a
code-walking version of SYMBOL-MACROLET. If SYMBOL-MACROLET were changed
to be a special form, this rule would no longer be needed, and should be
eliminated in order to make the distinction between symbol macros and
variables cleaner.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
∂22-Sep-88 1047 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 10:47:19 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA27618; Thu, 22 Sep 88 10:45:55 PDT
Date: Thu, 22 Sep 88 10:45:55 PDT
Message-Id: <8809221745.AA27618@decwrl.dec.com>
From: piazza%lisp.DEC@decwrl.dec.com (Jeffrey Piazza)
To: cl-cleanup@sail.stanford.edu
Subject: Issue SYMBOL-MACROLET-SEMANTICS, Version 4
[ Sorry-- I removed the language about SETQ from the proposal, but left it in
the Rationale by oversight. ]
Status: For Internal Discussion
Issue: SYMBOL-MACROLET-SEMANTICS
References: X3J13 document 88-002R, Chapter 2, pp. 2-81f.
Category: CHANGE
Edit history: 29-July-88, Version 1 by Piazza
21-September-88, Version 2 by Piazza
22-September-88, Version 3 by Piazza
22-September-88, Version 4 by Piazza
Problem Description:
The SYMBOL-MACROLET construct, introduced with CLOS in X3J13 document
88-002R, profoundly alters the interpretation of symbols appearing as
forms in a Common Lisp program--what previously was necessarily a variable
might now be a symbol macro instead. Macros which appear in the body of a
SYMBOL-MACROLET form are currently unable to determine whether a symbol
form is a variable or a symbol macro, and, if the latter, what the
expansion of the symbol macro is. Consequently, complex macros (such as
SETF or PUSH) which depend on the form of their argument(s), are unable to
produce their desired results in some cases, as in the following example:
(let ((a (make-array 5))
(i 0))
(symbol-macrolet ((place (aref a (incf i))))
(push x place))
i) ==> 2
Proposal (SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM):
Change the definition of SYMBOL-MACROLET to specify that it is a special
form, which affects the evaluation environment for symbols. Enhance
MACROEXPAND and MACROEXPAND-1 so that they can expand a symbol macro.
Modify SETF et al to use the new MACROEXPAND and MACROEXPAND-1 to examine
even symbol subforms. Specify that the expansion of a symbol macro IS
subject to further macro expansion in the same lexical environment as the
symbol macro invocation, exactly analogous to normal macros.
Rationale:
The potential for interaction between macros is exactly why &environment
arguments were originally added to macros. Changing SYMBOL-MACROLET to be
a special form, which communicates through the &environment arguments to
macros with MACROEXPAND and MACROEXPAND-1, would allow PUSH and SETF
(among others) to work with SYMBOL-MACROLET in the same way they work with
MACROLET.
This change cannot (reasonably) support the currently specified semantics
that the expansion text is "outside" the scope of the symbol macro. For
indeed, when the symbol macro is expanded, (a copy of) the expansion is
then within the scope of the SYMBOL-MACROLET, and should then be subject
to further scrutiny. The issue of "infinite expansion" of symbol macros is
no more dangerous than that of normal macros.
Current Practice:
Portable Common Loops provides a code-walking implementation of
SYMBOL-MACROLET as specified in 88-002R. Symbolics Cloe has both a
code-walking version of a SYMBOL-MACROLET macro and compiler support for
a SYMBOL-MACROLET special form.
Cost to Implementors:
If SYMBOL-MACROLET is modified to be a special form, compilers and
interpreters will have to change, as well as MACROEXPAND, MACROEXPAND-1,
PUSH, INCF, DECF, and others.
Cost to Users:
If SYMBOL-MACROLET is converted to a special form, code-walking programs
will have to be modified to handle SYMBOL-MACROLET correctly. Those same
programs would have to be modified to handle the other special forms
specified in CLOS, anyway.
Cost of Non-Adoption:
SYMBOL-MACROLET will retain its confusing semantics, leading to bugs when
it interacts with complex macros and forms which produce side-effects.
Implementations which support ONCE-ONLY will break. For that matter, any
mechanism which examines code and assumes that "variables" have no side
effects will break.
Benefits:
SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM avoids the hairiest problems
surrounding interaction of macros (like SETF) and side effects, and makes
SYMBOL-MACROLET consistent with MACROLET.
Aesthetics:
If SYMBOL-MACROLET is made to be a special form, aesthetics are improved
by making symbol macros consistent with normal macros.
Discussion:
A case could be made for adding a new function, SYMBOL-MACRO-FUNCTION, as
a dual of MACRO-FUNCTION. However, symbol macros are simpler than normal
macros: a symbol macro is associated with a single expansion form, rather
than an arbitrary function which computes the expansion. For this reason,
the augmented MACROEXPAND-1 proposed here can also fill the role of
SYMBOL-MACRO-FUNCTION: the second value of (macroexpand-1 sym env) will be
T if and only if sym is a symbol macro, while the first value gives the
expansion of sym, if it has one.
Also, Pitman points out that, rather than extending the existing
MACROEXPAND and MACROEXPAND-1 functions, new functions could be introduced
to expand symbol macros. However, there seems to be no particular reason
to do this.
∂22-Sep-88 1413 CL-Cleanup-mailer CLOS in the standard
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Sep 88 14:13:44 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 88 13:55:16 PDT
Date: 22 Sep 88 13:55 PDT
From: masinter.pa@Xerox.COM
Subject: CLOS in the standard
In-reply-to: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of Thu,
22 Sep 88 11:48:57 EDT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880922-135516-3060@Xerox>
What I voted on and what appears in the minutes is that CLOS is part of the
standard, as much as anything else in CLtL. Some people are considering ways of
making parts of the standard "optional" or somehow dividing it, but those would
have to come as future proposals. Given the votes for and against, I think you
voted for the same motion. "for inclusion in the Common Lisp language being
specified by this committee" doesn't mean "as an optional component", any more
than sequence functions or format or ED, TRACE and BREAK are optional.
I'm suprised by your remark. Since "the usual editorial and cleanup processess"
means that this committee will be handling some of the CLOS-related changes, I'd
have expected to hear from you before now if you were going to propose to make
CLOS "optional".
- - - - - - - -
Subject: DRAFT Minutes June meeting
From: MATHIS@A.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU] 7-Jul-88 10:29:46.MATHIS>
DRAFT
Minutes of the X3J13 Meeting, Boston, June 15, 16 1988.
....
Dick Gabriel moved, and Larry Masinter seconded, to change the
motion to the following:
The X3J13 Committee hereby accepts chapters 1 and 2
of the Common Lisp Object System, as defined in document
88-002R, for inclusion in the Common Lisp language being
specified by this committee. Subsequent changes will be handled
through the usual editorial and cleanup processes.
The motion passed 22-0.
The original motion, as amended, passed 24-1.
∂22-Sep-88 1722 CL-Cleanup-mailer LISP-SYMBOL-REDEFINITION
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 17:21:52 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07051g; Thu, 22 Sep 88 16:19:56 PST
Received: by bhopal id AA07323g; Thu, 22 Sep 88 17:19:20 PDT
Date: Thu, 22 Sep 88 17:19:20 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809230019.AA07323@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@Sail.stanford.edu,
unido!ztivax!kolb@seismo.CSS.GOV
In-Reply-To: David A. Moon's message of Sun, 18 Sep 88 15:17 EDT <19880918191704.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: LISP-SYMBOL-REDEFINITION
re: I guess we have to go with LISP-SYMBOL-REDEFINITION:DISALLOW. We
unfortunately have to include the part that prohibits lexically
shadowing (redefining is the wrong word here) functions in the ...
I very much dislike the use of "shadow" here, since it so readily invokes
the other meaning of SHADOW, which in fact has some bearing on the problem
(i.e., functions named by symbols with names like "IF" and "CAR"). At the
Palo Alto meeting in March of this year, I thought we started using the
term "lexical override"; or some such term. Anything but "shadow".
-- JonL --
∂22-Sep-88 1727 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 17:27:00 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07074g; Thu, 22 Sep 88 16:25:15 PST
Received: by bhopal id AA07353g; Thu, 22 Sep 88 17:24:43 PDT
Date: Thu, 22 Sep 88 17:24:43 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809230024.AA07353@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: TAGBODY-CONTENTS (version 1)
I'm happy with the restrictions proposed.
For the record, I believe the reason pdp10 MacLisp allowed numbers,
including flonums, as tags was that Ira Goldstein's LLOGO (a LOGO
system written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc. There
may be more to it, but I distinctly remember an event like this in
the distant past.
-- JonL --
∂22-Sep-88 1923 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 19:23:00 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07152g; Thu, 22 Sep 88 18:20:49 PST
Received: by bhopal id AA07675g; Thu, 22 Sep 88 19:20:19 PDT
Date: Thu, 22 Sep 88 19:20:19 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809230220.AA07675@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: GLS@Think.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Sun, 18 Sep 88 16:22 EDT <19880918202212.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
A number of comments on this first draft:
----
I raised this issue at the Fort Collins meeting last November, suggesting
that it was an unintended aberration in CLtL. But Guy Steele quickly
defended it, and promised to write down his objection to the "ALLOW"
interpretation and mail them out (this was in a plenary session, and was
only partially relevant to the item under discussion.) To date, I don't
recall seeing his objections, but he should cough them up now or forever
hold his peace.
----
The current statement of "the problem" isn't really right. Until you wrote
it in this message, I don't remember people saying that they thought locally
type declarations were "not valid Common Lisp". Rather, they were thought
to be un-useful declarations, since the compiler is forbidden to treat
variable references differently based on cognizance of that declaration
[i.e. declaration can affect "bindings", but not "references"]. In fact,
none of the half-dozen or so implementations I've tried this on during the
past year issued any warning or error in such cases. This is not to say
that at least some people didn't think it was "invalid"; merely that the
statistical sample leans toward the "un-useful" side. [Please, gang, no
puns on that last sentence.]
----
The proposal says:
Change the phrase "affects only variable bindings" to "concerns variable
bindings." . . .
Is this really an improvement? the change seems to have the exactly the
same potential for misinterpretation as the original. Admittedly, with
the subsequent clarification, one is less inclined to think so; then again,
one might simply think the specification is inconsistent.
----
Surely, the matter must be related somewhat to the issue of how a compiled
local variable will be implemented. Pdp10 MacLisp would "home" fixnum and
flonum variables on stacks distinct from the one normally used for function
call frames (or "activation records" or whatever you favorite buzz word for
this concept). These alternate stacks -- the FXPDL and FLPDL -- were
incapable of holding data not of the declared type; so in that world:
(let ((x <some-value>))
(declare (fixnum x))
(somehow-ignore x)
(setq x 5)
...)
would be compiled radically differently from:
(let ((x <some-value>))
(locally (declare (fixnum x))
(somehow-ignore x)
(setq x 5)
...))
since the former implementationally restricts the value of <some-value>
to be a fixnum, whereas the latter permits it to be, for one instant at
the time of binding, any old random type. The S1/NIL implementation
expected to have a "pdlnum" scheme similar to pdp10 MacLisp's, so I would
think that CLtL's restriction is due to Guy's experience in trying to
accommodate this implementational technique. At the very least, the
proposal needs to show cognizance of the difference between a compiler's
type information propogation (and inferencing) and of the constraints
imposed by the compiler's choice of "slots" to hold variables' values.
However, I don't believe any vendor today except Lucid employs this
implementational technique; and Lucid has already long since jumped
ahead on this mater to give the locally type declarations their
obvious meaning -- namely, semantically equivalent to wrapping a
(the <type-specifier> ...) around each reference to the variable.
[Incidentally, in Lucid's implementation, the semantic difficulty
refered to in the previous paragraph -- about "affecting the binding"
-- manifests itself as a performance pessimization rather than any
inconsistency or incorrectness in the code. so it says here.]
Some thoughts like these ought to be in the proposal before it is
submitted to the committee as a whole.
-- JonL --
∂22-Sep-88 2211 CL-Cleanup-mailer Re: Issue: DECLARE-FUNCTION-AMBIGUITY (version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Sep 88 22:11:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 88 22:09:26 PDT
Date: 22 Sep 88 22:09 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-FUNCTION-AMBIGUITY (version 1)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 22 Sep 88
10:34:17 CDT
To: David N Gray <Gray@DSG.csc.ti.com>
cc: vanroggen%aitg.DEC@DECWRL.DEC.COM, cl-cleanup@SAIL.STANFORD.EDU
Message-ID: <880922-220926-3835@Xerox>
(I thought I had sent out mail asking to please rename this issue.. from
FUNCTION-DECLARATION?)
I think the major motivation for this for me is that the FUNCTION-TYPE proposal,
adopted at the last meeting, now makes (DECLARE (TYPE FUNCTION a b c))
meaningful where it was not before (or certainly no compiler that I know of
could take advantage of a declaration that var1 was either a symbol or a
function object.)
Now that (DECLARE (TYPE FUNCTION a b c)) is meaningful, the use of (DECLARE
(FUNCTION a b c)) now might seem ambiguous, since it could mean
(DECLARE (FTYPE (FUNCTION b c) a))
or
(DECLARE (TYPE FUNCTION a b c ))
The only simple way of disambiguating between these is that in the first
interpretation, b must be a list, while in the second, b must be a symbol.
(Declaring NIL to be a function is an error, so it should be treated as a list.)
I'm having trouble coming up with an example that is a real ambiguity. We still
may not like the appearance of ambiguity, even though there is none, but it
weakens the argument.
∂22-Sep-88 2230 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Sep 88 22:30:07 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 22 SEP 88 22:25:53 PDT
Date: 22 Sep 88 22:25 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DECLARE-TYPE-FREE (Version 3)
To: CL-Cleanup@sail.stanford.edu
Message-ID: <880922-222553-3848@Xerox>
I added a reference to DECLARATION-SCOPE. I added a Discussion section. I
changed "Most people interpret..." to "Some people interpret..." in the problem
discussion, since we need not argue about how many people think that it is valid
Common Lisp.
Ready for release? (regrets only, please)
!
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Problem description:
Some people interpret CLtL's phrase "(TYPE type var1 var2 ...) affects
only variable bindings" to mean that code such as the following is
not valid Common Lisp, because a type declaration can only be attached
to a binding, not used free.
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable to
be not a member of the declared type, within the scope of the
declaration. Clarify that this makes the above program a valid program
and that this kind of declaration means the same thing as inserting
THE in every reference to the variable and every setq of the variable.
Clarify that if nested type declarations refer to the same variable,
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
There is no strong reason to forbid this usage, and people have
often asked for it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already, with a warning that
it is an extension to Common Lisp.
Cost to Implementors:
None, it is valid to ignore type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
The above example will not have to be written in the following silly way,
which only works if x and y are used read-only:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(let ((x x) (y y))
(declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
Esthetics:
This provides a clean and simple way for the programmer to express what
she knows about the values a variable may take on within a certain
region of the program. Different compilers will use this information in
different ways; it's most aesthetic for the portable language to be free
of assumptions about how the compiler will use this information.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope
of declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at length. There is some possibility
that current implementations might be able to generate more
efficient code when declarations are associated with a particular
binding, e.g.,
(let ((x v)) (declare (type fixnum x)) (+ x x))
might be more efficient than
(let ((x v)) (locally (declare (type fixnum x)) (+ x x)))
However, the local type declarations allowed by this proposal
do provide useful information even when it is not the *most* useful.
∂22-Sep-88 2249 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 22 Sep 88 22:48:57 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA07223g; Thu, 22 Sep 88 21:47:10 PST
Received: by blacksox id AA01432g; Thu, 22 Sep 88 22:44:55 pdt
Date: Thu, 22 Sep 88 22:44:55 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809230544.AA01432@blacksox>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 22 Sep 88 22:25 PDT <880922-222553-3848@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 3)
Date: 22 Sep 88 22:25 PDT
From: masinter.pa@Xerox.COM
Benefits:
The above example will not have to be written in the following silly way,
which only works if x and y are used read-only:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(let ((x x) (y y))
(declare (fixnum x y))
...algorithm using x and y...)
...similar algorithm using x and y...)
I would remove the adjective "silly" from this description. I don't
find this especially silly.
∂22-Sep-88 2253 CL-Cleanup-mailer Re: Issue: DECLARE-TYPE-FREE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 22 Sep 88 22:53:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 22 SEP 88 22:51:39 PDT
Date: 22 Sep 88 22:51 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DECLARE-TYPE-FREE (Version 3)
In-reply-to: Eric Benson <eb@lucid.com>'s message of Thu, 22 Sep 88 22:44:55 pdt
To: Eric Benson <eb@lucid.com>
cc: masinter.pa@Xerox.COM, CL-Cleanup@sail.stanford.edu
Message-ID: <880922-225139-3866@Xerox>
OK. Consider Version 3 doesn't have the word "silly" in it.
∂23-Sep-88 0017 CL-Cleanup-mailer Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 00:17:26 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 00:14:20 PDT
Date: 23 Sep 88 00:14 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3)
TO: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
line-fold: NO
Message-ID: <880923-001420-3926@Xerox>
Ready for release? NACKs only.
!
Issue: DEFSTRUCT-SLOTS-CONSTRAINTS-NAME
References: CLtL p.308 & 86-003 p.4
Category: CLARIFICATION
Edit history: Version 1 by Skona Brittain 05/13/88
Version 2 by Larry Masinter 14-Sep-88
Version 3 by Larry Masinter 23-Sep-88
Problem Description:
The case of two slots of a structure having the same name is not
discussed in CLtL. Is it allowed?
Proposal (DEFSTRUCT-SLOTS-CONSTRAINTS-NAME:DUPLICATES-ERROR):
It is an error for two slots in a structure type to have the same symbol-name;
that is, the SYMBOL-NAME of the slot names should not be STRING=.
This holds when they were both named directly by the same call to defstruct
or when one is present by virtue of being in an included structure.
The situation of expanding a DEFSTRUCT macro with a duplicate name should
signal an error. (While not yet formally defined, the intent is that
the error signalling may occur when compiling a file that contains
duplicate names or when evaluating a DEFSTRUCT form with duplicate names
in an interpreter.)
Test Cases:
(defstruct struc slot slot) would be an error. So would
(defstruct (struc2 (:include struc1)) slot) if preceded by
(defstruct struc1 slot).
Rationale:
Since it would be difficult to prescribe reasonable behavior for
this situation, it should be considered an error.
Current Practice:
In KCL, if two slots have the same name, no warning message is
given but mysterious behavior ensues. (Their default values are
both whatever is given for the second one, neither can be given a
different value via a call to the constructor function, only the
second one's value can be changed by setf...)
Cost to Implementors:
None.
Cost to Users:
None.
Cost of Non-Adoption:
Possible confusion.
Benefits:
Clarity.
Aethetics:
Something that is not well-defined and leads to erratic behavior
should be explicitly considered an error.
Discussion:
Although this issue was mentioned in Guy's original issues file, it has
not been officially discussed since.
This issue was first circulated to X3J13 June 1988.
∂23-Sep-88 0021 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88 00:21:08 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA07282g; Thu, 22 Sep 88 23:19:22 PST
Received: by bhopal id AA08357g; Fri, 23 Sep 88 00:18:50 PDT
Date: Fri, 23 Sep 88 00:18:50 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809230718.AA08357@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 20 Sep 88 00:37 PDT <880920-003738-3287@Xerox>
Subject: Issue: PACKAGE-CLUTTER
re: When you're about to release Lucid Common Lisp version 17, you'll be
glad that we made the default for :USE be LISP so that you could support
users who want to
:USE '("LUCID-3-0") ?
What's today a vendor-to-vendor issue is as likely to become a
version-to-version issue for you, no?
Absolutely not; in fact, I think you have it backwards. The simple path
of porting from and old version release to a newer one is SURELY thwarted
if the end user's code has calls like:
(make-package ... :use '("LUCID-3-0"))
Only when the customer takes the default use list will he get the documented
environment. Consider when *default-make-package-use-list* changes from
("LISP" "LUCID-COMMON-LISP")
to:
("LISP" "LUCID-COMMON-LISP" "LU-GRAPHICS")
[I did mention didn't I that the extensions are found in a package that is
not version dependent -- namely, LUCID-COMMON-LISP.] In effect, Lucid
has guaranteed that at least the LISP and LUCID-COMMON-LISP packages will
be around, and that they will be changed to meet the demands of the Common
Lisp Language and of Lucid's primary extensions thereto.
The place for the explicit :use list is for "portable" code -- it doesn't
want any of the vendor-specific stuff from the old release, and it doesn't
want any from the new release either!
One must remember that porting code from older releases to newer ones does
require user involvement. For a programmer who makes use of the vendor-
specific extensions, it cannot be solved merely by restricting the package
use list. Successive releases of Vendor Common Lisp will no doubt have a
few more symbols in them than earlier releases had [sigh, not likely that
very many will be removed]. An explicit :use list in customer package
creations will not shield him against such additions or deletions; but in
fact could put him in an partial environment that doesn't make much sense.
Of course, there will be applications which do want to supply an explicit,
non-default :use list -- for example:
("LISP" "SYSTEM" "VENDOR-COMMON-LISP" "GRAPHICS")
and these will require more than the usual amount of attention when the
vendor inflicts a major release cycle upon that community. Not only will
such users have to peruse the differential documentation, but they will have
to peruse all their code for :use lists that may no longer be workable.
-- JonL --
∂23-Sep-88 0125 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 01:24:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 01:15:03 PDT
Date: 23 Sep 88 01:15 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880923-011503-3968@Xerox>
I've made several changes to the proposal, only some of which were justified by
the discussion:
I explicitly said that LISP might have additional internal symbols.
I eliminated the requirement that there be a SYSTEM package.
(This is out of the blue. Exactly what belonged in SYSTEM vs STORAGE-ALLOCATOR
or FILE-SYSTEM always baffled me. )
I made explict that USER might contain implementation-specific symbols,
as well as using implementation-specific packages.
I mentioned that CLOS and the condition system might have their
own packages.
I think we might be able to pass a package-clutter issue and deal with a new
issue MAKE-PACKAGE-USE-DEFAULT separately, or possibly as an amendment to this
one.
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Issue: DEFPACKAGE
Issue: IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Those symbols with function, variable, macro, setf, constant definitions
or uses as properties or tokens may have no other additional definitions
other than those specified.
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available.
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it may
not be bound, defined as a type, or defined as a function, macro or
special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Symbolics Genera currently has exactly the set of symbols on it which is
prescribed by CLtL. A few symbols, such as EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables. The symbol LAMBDA is defined
as a macro. There may be a few other exceptions like this.
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This issue came up a while back on Common-Lisp list. The issue
of whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
There is considerable debate in the cleanup committee whether the default
value for the :USE keyword in IN-PACKAGE, MAKE-PACKAGE (and
the proposed DEFPACKAGE) should be changed to be implementation
specific. This version of the proposal leaves the default value as specified
in CLtL, namely, that it is the "LISP" package.
There was not consensus on this sub-issue; it could be handled as a separate
issue, if this proposal is endorsed by X3J13.
∂23-Sep-88 0125 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 01:25:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 01:18:51 PDT
Date: 23 Sep 88 01:19 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
In-reply-to: Jon L White <jonl@lucid.com>'s message of Fri, 23 Sep 88 00:18:50
PDT
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <880923-011851-3969@Xerox>
(I thought I'd mailed this, but apparently I left it pending while I rewrote
PACKAGE-CLUTTER. Since I'm hoping to split out the default from :USE from the
issue of what's actually in the Lisp package, I've put this under a different
Issue name.
- - - - - - - -
One of the complaints I hear frequently about Common Lisp is how non-portable it
is -- how people with Common Lisp code had to work really hard to port their
stuff from Vendor 1 to Vendor 2 even on the same machine, and that it must be
really not a very good language definition compared to C. I usually think this
is backward, and isn't CL great how it is even portable across machines with
different word sizes.
But then I get to issues like this, where if you write a simple program that
says
(in-package "FROB")
(defun draw-line (x y) ...)
that when they go to port it to Vendor y, they find out that their simple
program crashes the graphics package because draw-line now has the wrong
arguments. "I meant FROB:DRAW-LINE, not some LU-GRAPHICS:DRAW-LINE."?
I think this is the same argument that Kent made, so I won't belabor it. Maybe
the lines are drawn fairly clear. Its a tradeoff of encouraging portability vs
convenience for users of a specific implementation.
∂23-Sep-88 0134 CL-Cleanup-mailer Issue: DESCRIBE-INTERACTIVE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 01:34:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 01:32:48 PDT
Date: 23 Sep 88 01:33 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DESCRIBE-INTERACTIVE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880923-013248-3976@Xerox>
I added some discussion, changed some of the wording to reflect that
this might be as a change rather than a clarification.
!
Issue: DESCRIBE-INTERACTIVE
References: DESCRIBE (p441)
Category: CLARIFICATION/CHANGE
Edit history: 12-Sep-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
Problem Description:
CLtL is not clear about whether DESCRIBE may be interactive.
While CLtL describes INSPECT as an interactive as an
interactive version of DESCRIBE, it doesn't make explicit
that DESCRIBE is non-interactive. In some implementations it is,
and in other implementations it is not.
Users of systems in which DESCRIBE is not interactive may presume
that it is safe to call DESCRIBE in a batch applications without
hanging the application, which can lead to problems.
Proposal (DESCRIBE-INTERACTIVE:EXPLICITLY-VAGUE):
Specify that DESCRIBE is permitted (though not required) to
require user input, and that such input should be negotiated
through *QUERY-IO*.
Descriptive information would continue to go to *STANDARD-OUTPUT*.
Test Case:
The following kind of interaction would be permissible in
implementations which chose to do it:
(DEFVAR *MY-TABLE* (MAKE-HASH-TABLE))
(SETF (GETHASH 'FOO *MY-TABLE*) 1)
(SETF (GETHASH 'BAR *MY-TABLE*) 2)
(SETF (GETHASH 'FOOBAR *MY-TABLE*) 3)
(DESCRIBE *MY-TABLE*)
#<EQ-HASH-TABLE 259> has 3 entries.
Do you want to see its contents? (Yes or No) Yes
Rationale:
This validates current implementations.
Current Practice:
Symbolics Genera asks some questions interactively when describing
some kinds of structured data structures, such as hash tables.
Since users can define their own DESCRIBE methods and took their cue
from the system, describing some user structures also require such
interactions.
Cost to Implementors:
None.
Cost to Users:
User code which depended on DESCRIBE running without user interaction
would have to be modified. Such code is not currently fully portable,
however.
Cost of Non-Adoption:
Users would not know the straight story about whether they should
expect interaction from DESCRIBE.
Benefits:
Implementations which don't do interactive querying in DESCRIBE only
because their not 100% sure it's kosher would be free to do it.
Aesthetics:
Some people might think it's not aesthetic for DESCRIBE to require user
intervention. Not saying whether it's permissible is probably less
aesthetic, though.
Discussion:
Pitman thinks it's important to clarify this issue, but he isn't fussy
about the particulars.
This proposal is the minimal proposal for compatibility with current
behavior.
It might be possible to extend DESCRIBE to have additional
keywords (:VERBOSE, :INTERACTIVE-ALLOWED) to cover
additional behavior.
Some members of the cleanup committee think that this is really
a change from the intent of CLtL. However, the current sentiment
is to be less rather than more specific about the behavior of debugging
tools (25.3 of CLtL).
∂23-Sep-88 0242 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 02:42:51 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 02:13:29 PDT
Date: 23 Sep 88 02:13 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 3)
TO: cl-cleanup@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <880923-021329-3994@Xerox>
Ready for release?
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
(CONSes, bit-vectors, strings, pathnames). EQUAL uses EQL
for numbers and EQ for all other types.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of extensions,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives. Aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
We considered:
removing EQUAL and EQUALP from the standard.
changing EQUALP to descend structures.
changing EQUALP to be case sensitive.
adding a :TEST keyword to EQUAL.
making EQUAL a generic function
All of these had some serious problems.
∂23-Sep-88 0243 CL-Cleanup-mailer Re: Issue FIXNUM-NON-PORTABLE (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 02:42:58 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 02:37:28 PDT
Date: 23 Sep 88 02:37 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue FIXNUM-NON-PORTABLE (Version 2)
to: cl-cleanup@sail.stanford.edu
Message-ID: <880923-023728-4008@Xerox>
OK?
!
Issue: FIXNUM-NON-PORTABLE
References: CLtL p. 14, 34, 43, 231
Category: CHANGE, CLARIFICATION
Edit History: Version 1, 15-Sep-88, Masinter
(based on Issue BOGUS-FIXNUM)
Version 2, 23-Sep-88, Masinter
Problem Description:
Implementations of Common Lisp are required to support two disjoint
subsets of integers, fixnums and bignums, with the promise that
fixnums have a more efficient representation. However, nothing is
guaranteed about the range of integers which are fixnums: "Exactly
which integers are fixnums is implementation-dependent; typically they
will be those integers in the range -2**n to 2**n - 1, inclusive, for
some n not less than 15."
There are few uses of the fixnum type that are portable, given the
current definition. In particular, many programmers use FIXNUM type
declarations where they really mean "small integer".
While most Common Lisp implementations have a FIXNUM range
which is a subset of integers represeted and operated on most
efficiently, many also have several other subranges. The
partitioning of INTEGER into BIGNUM and FIXNUM is merely
confusing in these implementations, and not useful.
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(1) Change the description of the type FIXNUM to reflect that it is
required to be a supertype of (SIGNED-BYTE 16).
(2) remove the type BIGNUM from the language.
Rationale:
Many programmers already use FIXNUM to mean "small integer"; this
proposal makes this usage portable.
However, there is little portable use for the type BIGNUM, and it
is inconsistent with many current implementation techniques.
Current Practice:
Xerox Common Lisp has 17-bit fixnums. Most other Common Lisp
implementations have fixnum ranges of 24 bits or larger. We know
of no implementation that currently violates the proposed minimum
size.
Several existing Common Lisp implementations have more than two
representations for integers, such that the FIXNUM/BIGNUM distinction
is confusing.
Cost to implementors:
Slight. All implementations we know of already define FIXNUMs to be at
least 16 bits and would only have to remove the BIGNUM type specifier
to be in compliance with the proposal.
Cost to users:
Slight. The removal of the BIGNUM type specifier will affect user code
but it appears to be little-used.
Benefits:
The FIXNUM type specifier would have a portable interpretation.
The language would be less confusing.
Discussion:
Earlier discussion of a related proposal contained several other more controversial
components (adding a constant MAX-INTEGER-LENGTH, allowing
MOST-POSITIVE-FIXNUM to be NIL as well as an integer.) This proposal
is an attempt to address the part that cleanup committee seemed to agree on.
It is possible that an implementation have a single representation for all
integers, and no way to identify any efficient range of integers. Those
implementations might need to set MOST-POSITIVE-FIXNUM
and MOST-NEGATIVE-FIXNUM to arbitrary values, consistent with
the requirement that (SIGNED-BYTE 16) is a subtype of FIXNUM.
Other alternatives considered (and not necessarly mutually exclusive
with this proposal):
remove the FIXNUM type specifier entirely, while leaving a way
to query what is the most efficient range of integers
leave the range of FIXNUMs unconstrained and introduce a
SMALL-INTEGER type with a fixed range (but no promises about
efficiency) .
guarantee that the value of the constant ARRAY-TOTAL-SIZE-LIMIT be a
fixnum (for efficient array addressing)
It might be possible to specify the required performance behavior
of FIXNUMs more concretely, e.g., specify that the basic integer operations
use algorithms that are not proportional to the size of the data; it
should be just about as fast to add numbers in the middle of the fixnum
range as it is to add, say, 10 and 11. This might be a useful way to describe
the intent of the FIXNUM range, if not its specification.
∂23-Sep-88 0709 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 23 Sep 88 07:09:29 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 23 Sep 88 10:06:53 EDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
In-reply-to: Your message of 23 Sep 88 01:15:00 -0700.
<880923-011503-3968@Xerox>
Date: Fri, 23 Sep 88 10:06:14 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Those symbols with function, variable, macro, setf, constant definitions
or uses as properties or tokens may have no other additional definitions
other than those specified.
...
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it may
not be bound, defined as a type, or defined as a function, macro or
special form.
...
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
Where did this come from? I am vehemently opposed to this, if you intend
this restriction to apply to users as well as to implementors. We've got a
language that, for better or worse, has separate namespaces for functions
and variables, and additional namespaces for properties and flags of
various kinds. Just because Lisp pre-empts the use of some symbol as a
function name does not mean that users should be prevented from using it as
a variable name or marker in a property list.
If we impose this restriction now, we are creating a very large "cost of
adoption". Just as one example, every user program that uses LIST or
SYMBOL or MEMBER as a local variable will have to be altered.
If we want to say anything along these lines, we should say that
*implementors* must not use these exposed symbols in additional,
undocumented ways within their implementations, since users can get hold of
these symbols and use them in conflicting ways.
-- Scott
∂23-Sep-88 0847 CL-Cleanup-mailer Issue: PRINT-PRETTY-HOOK (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88 08:47:52 PDT
Received: from rainbow-warrior ([192.9.200.16]) by heavens-gate.lucid.com id AA07506g; Fri, 23 Sep 88 07:46:05 PST
Received: by rainbow-warrior id AA24733g; Fri, 23 Sep 88 08:44:24 PDT
Date: Fri, 23 Sep 88 08:44:24 PDT
From: Patrick Dussud <dussud@lucid.com>
Message-Id: <8809231544.AA24733@rainbow-warrior>
To: pierson%mist@multimax.ARPA
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dan L. Pierson's message of Thu, 22 Sep 88 10:29:09 EDT <8809221429.AA13532@mist.UUCP>
Subject: Issue: PRINT-PRETTY-HOOK (version 1)
Date: Thu, 22 Sep 88 10:29:09 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Would it help if the pretty print function took an additional optional
argument, the current print level (the current print length always
starts at 0 when the function is called.)
I think it makes it more consistent with the structure print functions. I
don't think that you can win all the time, because, if your print function
calls a Common Lisp print function (print, princ...), then you lose the depth.
Patrick.
∂23-Sep-88 0901 CL-Compiler-mailer Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 09:01:08 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA24818; Fri, 23 Sep 88 09:59:42 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA02377; Fri, 23 Sep 88 09:59:14 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8809231559.AA02377@defun.utah.edu>
Date: Fri, 23 Sep 88 09:59:12 MDT
Subject: Re: Issue: COMPILE-FILE-ENVIRONMENT (Version 1)
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: cl-cleanup@sail.stanford.edu,
Sandra J Loosemore <sandra%defun@cs.utah.edu>, Gregor.pa@xerox.com,
cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 21 Sep 88 14:23 EDT
I'd like to put this issue on hold for the time being. Since it
appears that CLOS depends on storing some other information in
environment objects besides the information about MACROLETs in the
surrounding lexical environment (the only thing that CLtL requires), I
think a more general proposal to clarify what goes in environment
objects is in order. And, I don't think that really falls into the
domain of the compiler committee.
-Sandra
-------
∂23-Sep-88 0913 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 09:13:34 PDT
Received: by rice-chex.ai.mit.edu; Fri, 23 Sep 88 12:12:45 EDT
Date: Fri, 23 Sep 88 12:12:45 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8809231612.AA00588@rice-chex.ai.mit.edu>
To: masinter.pa@xerox.com
Cc: gls@think.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@xerox.com's message of 20 Sep 88 11:35 PDT <880920-113534-4339@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
----------
Issue: STREAM-INFO
References: FORMAT ~T (pp398-9) and ~<...~> (pp404-6), PPRINT (p383)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman (2d model)
23-Jun-88, Version 2 by Waters (1d model, modified 2d model)
24-Jun-88, Version 3 by Pitman (minor reformatting)
24-Jun-88, Version 4 by Pitman (remove 2d model for submission)
23-Sep-88, Version 5 by Waters (cleaned up in response to discussion)
Status: For Internal Discussion
Problem Description:
Currently, there is no portable way to inquire about the line width of
an output stream, the current position on a line, or the amount of
space that the display of a string will take up. This makes it
essentially impossible to write a portable implementation of a pretty
printer.
Proposal (STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS):
Introduce four new functions.
These functions are carefully designed with an eye to the way they
interact. As a result, they can only be defined fully in terms of
each other. The presentation below first gives a very brief
definition of each function and then gives detailed specifications of
their relationships.
LINE-WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the line width available
when printing to OUTPUT-STREAM. If the stream has no meaningful
width (or the width cannot be computed) then NIL is returned.
LINE-POSITION &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [Function]
Returns a non-negative integer representing the current horizontal
position on the current output line, or NIL if the position cannot
be computed.
WRITE-SPACE WIDTH &optional (OUTPUT-STREAM *STANDARD-OUTPUT*) [function]
Inserts blank space of length WIDTH into OUTPUT-STREAM. WIDTH must
be a non-negative integer. WRITE-SPACE returns T if the operation
is successful and NIL otherwise (e.g., if the operation is not
supported by OUTPUT-STREAM).
PRINTED-WIDTH STRING &optional (OUTPUT-STREAM *STANDARD-OUTPUT*)
&key (START 0) (END NIL) [Function]
Returns an integer representing the horizontal width that would be
required to display STRING if it were written at the current moment
to OUTPUT-STREAM using (WRITE-STRING STRING OUTPUT-STREAM :start
START :end END), or NIL if this width cannot be computed. The width
may be negative (e.g., if STRING contains backspace or newline
characters.)
PRINTED-WIDTH does not return any indication of the vertical
distance required when printing STRING. The START and END
parameters delimit a substring of STRING in the usual manner.
PRINTED-WIDTH never causes any change in the state of OUTPUT-STREAM.
The width returned may well depend on the current state of
OUTPUT-STREAM (e.g., the width of tabs depends on the line position
and the width of characters depends on the font in use.) In all
respects the width is computed based on the current state of the
stream. However, the width returned always assumes that the total
line width is infinite---i.e., does not reflect any wraparound or
truncation which might occur.
-The difficulties of a full specification:
The functions above are intended to solve a specific current problem
in CL. To serve this purpose, they must have reasonably precise
specifications. However, there are several things which make it
desirable to have specifications which allow for significant
variability between implementations. First, current implementations
of CL differ greatly in the way IO is supported, and overly strict
specifications might make things very difficult for certain
implementations. Second, CL places no limits on the kinds of
idiosyncratic characters which can be supported by particular
implementations. Third, while many CL implementations only support
the printing of characters in fixed width fonts, it is desirable to
allow for output streams that support variable width fonts.
Finally, it is desirable to leave room to move for the future.
-Operations on standard characters where the line-width has not yet been exceeded.
To deal with the problems above, a layered specification is
provided. The lowest level specification is given in terms of
constraints between the four functions above. In this lowest level
specification, two key simplifying assumptions are made. First, it
is assumed that at the time the constraint applies, none of the
previous operations on the stream S in question have caused output
to go beyond the physical horizontal limits of the output device on
the output lines relevant to the constraints. I.e., it is assumed
that truncation and or wraparound of the output has not occurred on
these lines. Second, it is assumed that all of the characters
output to the stream on the output lines relevant to the constraints
are standard characters as defined in CLTL pp 20-21. The
non-standard character #\newline may have been used to end one line
and start the next. (Note that standard characters are all simple
characters such as A-Z. Particularly, #\tab, #\backspace,
#\newline, are NOT standard characters.) It is further assumed that
the strings (X and Y) referred to in the constraints consist solely
of standard characters.
Basic properties of LINE-POSITION:
1- For all S, (not (minusp (line-position S)).
2- For all S, (zerop (line-position (progn (terpri S) S))).
3- For all S, If something is at line position N on one line and
something else is at line position N on another line, then the
two things are lined up vertically one under the other.
Defining property of WRITE-SPACE
4- For all N,S, let M = (+ (line-position S) N)
if M <= (line-width S), then
(= (line-position (progn (write-space N S) S)) M)
Defining property of PRINTED-WIDTH
5- For all X,S, let M = (+ (line-position S) (printed-width X))
if 0 <= M <= (line-width S), then
(= (line-position (progn (write-string X S) S)) M)
Basic property of LINE-WIDTH
6- For all N,S, let P = (line-position S)
If (+ P N) <= (line-width S) then
(write-space N S) is guaranteed to output space on the end of
the current line without any truncation of wraparound occurring.
7- For all X,S, let P = (line-position S)
If 0 <= (+ P (printed-width X)) <= (line-width S) then
(write-string X S) is guaranteed to output X on the end of
the current line without any truncation of wraparound occurring.
Additional properties of PRINTED-WIDTH
8- For all X,Y (= (printed-width (concatenate 'string X Y) S)
(+ (printed-width X S) (printed-width Y S)))
9- For all X,Z (= (printed-width X S)
(+ (printed-width X (write-string Z S))))
-Support for varying width fonts.
A key motivation behind the functions above is dealing with
arbitrary kinds of output devices and output streams that support
variable width fonts. To provide for this, the properties above
place no absolute constraints on the units used for the width
values. In fact, the units can vary from stream to stream. The
only thing that is required is that for a given stream, the units
must be a constant throughout the life of the stream, and the four
functions above must all operate in terms of the same units. The
units should be chosen to be small enough to represent the minimum
possible difference in the length of two strings and large enough
that it is possible to perform (write-space 1). (I.e., a single
pixel is a logical choice.)
If an output stream only supports a single fixed width font, then
the logical width unit to choose is the width of a single character.
Given this choice, the following is a minimal implementation of the
four functions that meets the requirements above.
LINE-WIDTH returns the maximum number of characters which can be
printed on a single line. LINE-POSITION returns the number of
characters output since the last #\newline (or since the creation of
the stream if no #\newlines have been output). (WRITE-SPACE N S)
outputs N #\space characters. Finally, (PRINTED-LENGTH X S) =
(length X).
-Support for non-standard characters and situations where line width
has been exceeded.
In the main, the properties above can be supported even if the line
width has been exceeded and even when non-standard charactres are
involved. However, characters such as #\tab and #\newline can make
it impossible to support properties 7 and 8. In addition, when the
line width is exceeded, property 3 may not hold. It is hoped that
implementors will make a good faith effort to support the functions
in the full range of situations which can be encountered in their CL
implementations. However, the simple implementation suggested above
will probably provide at least 80% of the benefits intended. As a
result, it is important that people not allow the potential
difficulties of a full implementation deter them from making a
minimal implementation.
-Support for derivative streams.
Intentionally, very little is said about what the width units should
be or exactly what LINE-WIDTH should return. The only key criterion
is that LINE-WIDTH should return a result that is pessimistic enough
to ensure proper printing. However, it is useful to make some
comments about these matters with regard to certain types of
derivative streams.
If a synonym stream, two way stream, or echo stream is created, it should
have the same line-width and width unit as the base output stream.
A string output stream should have a line-width of NIL and probably
should be treated as supporting a fixed width font and having an
output width unit so that each character has a printed-width of 1.
If a broadcast stream is created, then LINE-LENGTH, LINE-POSITION,
and PRINTED-WIDTH should be be supported by reflecting them through
to the FIRST base stream. (There is no guarantee that anything
reasonable can be done with the streams as a set. For example, one
might support a varying length font while the others don't.) An
attempt should be made to send WRITE-SPACE requests to all of the
base streams. However, they may not come out right on other than
the first base stream.
Test Case:
Suppose that S is an output stream that supports a single fixed
width font which can display 72 characters on a line and that the
associated width unit is the width of one character. Evaluating the
following will produce the results shown.
(line-width S) => 72
(terpri S) => nil
(output-position S) => 0
(printed-width "testing: " S) => 9
(write-string "testing: " S) => "testing: "
(line-position S) => 9
(write-string "foo" S) => "foo"
(terpri S) => nil
(write-space 9 S) => T
(write-string "bar" S) => "bar"
The output produced is
testing: foo
bar
Rationale:
Pretty printing requires the function LINE-WIDTH to know how wide the
output it produces can be. Pretty printing requires LINE-POSITION to
determine where on the line output is when pretty printing starts.
Pretty printing requires PRINTED-WIDTH to determine how much space
things will take in the output. (If a variable width font is being
used, this cannot be determined without a detailed knowledge of the
font being used.) (Properties 7 & 8 greatly reduce the number of
times PRINTED-WIDTH has to be called.) Pretty printing requires
WRITE-SPACE to get proper indentations. (If a variable width font is
being used, indentations may be required that cannot be obtained by
outputting spaces.)
Current Practice:
Essentially every implementation of Common Lisp must support the
minimal functionality above internally in order to support PPRINT and
the FORMAT directives ~T and ~<...~>. However, there is no documented
interface to this functionality in CLTL. As a result, while some
implementations of Common Lisp make this functionality available to
users, some do not. Further, the implementations that do provide
this functionality do so in a variety of incompatible ways.
Cost to Implementors:
This proposal is written in such a way as to allow implementations
which do not have the ability to compute difficult values to just
return NIL. Very little work is forced. The idea is to offer
implementors a common way to provide this useful information to
portable programs where possible.
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Complex output programs such as pretty printers cannot be written portably.
Benefits:
A wide range of programs can gain better control of the format of output.
Aesthetics:
No significant aesthetic impact other than a slight increase in the
number of functions defined.
Discussion:
Dick Waters submitted a request for changes along the line of the
horizontal aspects of these functions in a letter to X3J13 dated
June 14, 1988. Pitman and Waters wrote up the request formally.
STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS is the minimum which is
required to support pretty printing into a stream which
displays output using a variable width font.
We drafted an alternate proposal, STREAM-INFO:TWO-DIMENSIONAL-FUNCTIONS,
which goes significantly beyond what is needed merely for pretty printing
and provides primitives LINE-DIMENSIONS, LINE-POSITION,
PRINTED-DIMENSIONS, and WRITE-SPACE but it is not included here.
A key point of contention which would be likely to swamp the 2d proposal
is the age old question of how to handle the issue of vertical distance
(where is the origin, which way do you count, ...). If anyone would
prefer to see larger problem 2d proposal, it could be circulated, but at
the last minute Pitman got worried that even the 1d version was going to
be controversial enough and decided to keep things focused on that.
For his own needs, Waters is strongly interested in having either
ONE-DIMENSIONAL-FUNCTIONS or TWO-DIMENSIONAL-FUNCTIONS proposal accepted,
but does not care which. Pitman concurs.
One variation of the 1d proposal might be useful to consider:
PRINTED-WIDTH could return two additional values: the number of newlines
that WRITE-STRING of the string would execute and the maximum X position
encountered (which might differ from the first value if the number of
newlines was non-zero).
This feature wasn't necessary for Waters' minimalist proposal, but Pitman
would be willing to write it in here if people thought it would be useful
enough for other purposes.
The 5th version was changed from the 4th by responding to suggestions
about better names for the functions, including a discussion of how
line-width should apply to various kinds of derivative streams, and
most importantly, by including a much more precise specification for
what the minimal capabilities of the functions should be.
∂23-Sep-88 1353 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 13:53:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 13:47:24 PDT
Date: 23 Sep 88 13:47 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 4)
In-reply-to: dick@wheaties.ai.mit.edu (Richard C. Waters)'s message of Fri, 23
Sep 88 12:12:45 EDT
To: dick@wheaties.ai.mit.edu (Richard C. Waters)
cc: masinter.pa@Xerox.COM, gls@think.com, CL-Cleanup@sail.stanford.edu
Message-ID: <880923-134724-1961@Xerox>
I can think of several reasons for allowing these functions to return rationals
rather than integers. For example, if I have a mainly-fixed-width font, except
with a couple of oddball characters. It may be difficult and computationally
expensive to compute the lcm of the denominators of all of the rational widths
in a given postscript font -- especially if font metrics are normally
demand-loaded.
It would be more useful to remove any requirement on the scaling of the values;
if you want to print a short space, you can
(let((dot (printed-width ".")))
(if dot (write-space dot) (princ " ")))
∂23-Sep-88 1434 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 14:32:19 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 23 Sep 88 17:31:27 EDT
Received: by joplin.think.com; Fri, 23 Sep 88 17:29:25 EDT
Date: Fri, 23 Sep 88 17:29:25 EDT
From: gls@Think.COM
Message-Id: <8809232129.AA02644@joplin.think.com>
To: jonl@lucid.com
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Thu, 22 Sep 88 17:24:43 PDT <8809230024.AA07353@bhopal>
Subject: Issue: TAGBODY-CONTENTS (version 1)
Date: Thu, 22 Sep 88 17:24:43 PDT
From: Jon L White <jonl@lucid.com>
I'm happy with the restrictions proposed.
For the record, I believe the reason pdp10 MacLisp allowed numbers,
including flonums, as tags was that Ira Goldstein's LLOGO (a LOGO
system written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc. There
may be more to it, but I distinctly remember an event like this in
the distant past.
That is exactly what I recall.
--Guy
∂23-Sep-88 1447 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 14:47:38 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Fri, 23 Sep 88 17:35:56 EDT
Received: by joplin.think.com; Fri, 23 Sep 88 17:33:46 EDT
Date: Fri, 23 Sep 88 17:33:46 EDT
From: gls@Think.COM
Message-Id: <8809232133.AA03205@joplin.think.com>
To: jonl@lucid.com
Cc: Moon@stony-brook.scrc.symbolics.com, GLS@Think.COM,
CL-Cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Thu, 22 Sep 88 19:20:19 PDT <8809230220.AA07675@bhopal>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
Date: Thu, 22 Sep 88 19:20:19 PDT
From: Jon L White <jonl@lucid.com>
I raised this issue at the Fort Collins meeting last November, suggesting
that it was an unintended aberration in CLtL. But Guy Steele quickly
defended it, and promised to write down his objection to the "ALLOW"
interpretation and mail them out (this was in a plenary session, and was
only partially relevant to the item under discussion.) To date, I don't
recall seeing his objections, but he should cough them up now or forever
hold his peace.
Having pondered the matter, I have concluded that the me of September 1988
is considerably less wedged than the me of November 1987 (this follows from
the more general theorem that the me of now always judges itself less
wedged than me's of other times, past or future), and therefore I will
hold my peace.
In other words, I see the utility of the proposal, and have no overriding
objections that hold water.
--Guy
∂23-Sep-88 1539 CL-Cleanup-mailer away....
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 23 Sep 88 15:39:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 23 SEP 88 15:10:50 PDT
Date: 23 Sep 88 15:11 PDT
From: masinter.pa@Xerox.COM
Subject: away....
To: cl-cleanup@sail.stanford.edu
Message-ID: <880923-151050-2177@Xerox>
Unfortunately, something has come up, and I will be away for at least a week.
I've updated the cl-cleanup directory on arisia.xerox.com
The directory clcleanup/release has the 10 issues that I'd gotten to that are
"Ready for release?" so far.
The directory clcleanup/mail has my personal mail of back mail on issues (in the
Xerox local "Lafite" format, unfortunately).
If I can ask your assistance, if there are issues where you have suggestions or
improvements, it will help if you can mail out revised versions rather than just
critiques.
∂23-Sep-88 1705 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 23 Sep 88 17:04:58 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA08083g; Fri, 23 Sep 88 16:02:45 PST
Received: by bhopal id AA11135g; Fri, 23 Sep 88 17:02:14 PDT
Date: Fri, 23 Sep 88 17:02:14 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809240002.AA11135@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: masinter.pa@Xerox.COM, CL-Cleanup@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 20 Sep 88 13:36 EDT <19880920173616.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
re: ... I simply don't buy your arguments. ...
I think all your arguments are variations on: using symbols
with package prefixes in a DEFPACKAGE form is more dangerous than
using symbols with package prefixes in other forms. My position
is that DEFPACKAGE is no different from anything else in this respect.
Either you are not reading the same May criticisms, or you're not
understanding them fully. In very simplified form, they are:
-- Everything done by :IMPORT can be done with :IMPORT-FROM; thus
:IMPORT is redundant (and similarly for :SHADOWING-IMPORT).
-- :IMPORT _requires_ symbols and cannot accept strings; thus
:IMPORT-FROM has greater flexibility;
-- At package-creation time the user can, with proper imports, virtually
subsume all need for double-colon syntax in the remaining code; but
his purpose is defeated if he has to use double-colons in the creator
expression. [We discuss elsewhere how double-colons cause trouble].
Only one of the three arguments is about the danger of altering other
random packages while merely *** reading in *** some package creator
expressions. I'm really surprised that you haven't seen this problem
before, since DEFPACKAGE is in fact nothing beyond the capability now
in use of doing (PROGN (SHADOW...) (EXPORT ...) (USE-PACKAGE ...) ...)
[Incidentally, the problem is never caused by just "using symbols with
package prefixes", but rather by using double-colon prefixes. I'm sure
you're aware of that already.]
At least with top level calls to IMPORT, you can say either:
(A) (import 'loser::bar)
(B) (import (intern "BAR" "LOSER"))
(C) (import (or (find-symbol "BAR" "LOSER") (error "Missing Symbol")))
but in the current state of the DEFPACKAGE proposal, there is no capability
equivalent to (B) or (C) for the :IMPORT option. Hence the desirabililty
of not adding a *dangerous* construct to the language when a harmless one
-- :IMPORT-FROM -- is already planned.
The point of all this not to say that defpackage as proposed is guaranteed
to cause irreconcilable name-conflict problems. Rather, I think that the
penalty for minor order-of-event mistakes should be a continuable error
signalled before the damage is done, rather than the situation that Richard
Greenblatt described at the Fort Collins meeting.
The last mail interchange back in May concerned whether or not :IMPORT-FROM
should complain if the requested symbol didn't already exist, or whether
it should take the possibly dangerous step of creating it quietly. A part
of that interchange is copied below, since it is highly relevant to the
"dangerousness" issue.
-- JonL --
Date: Fri, 27 May 88 18:04:22 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: Moon@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 24 May 88 16:55 EDT <19880524205536.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: [More on] Issue: DEFPACKAGE
. . .
re: Okay, you're proposing that :IMPORT-FROM be changed to do something
different from any of the previous proposals, namely to call
FIND-SYMBOL instead of INTERN or the secret version of INTERN that ...
This is wrong. Your message of "Wed, 23 Mar 88 14:49 EST", which was the
presentation of (Version 2), said the following about :IMPORT-FROM (and
:SHADOWING-IMPORT-FROM):
(:IMPORT-FROM {(package-name {symbol}*)}*)
(:IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined. The second syntax is a
convenient abbreviation when only one package is specified.
Note that only the name of each argument symbol is used. The
actual symbol that gets imported is not necessarily the one
given as an argument; it's a symbol with that name accessible in
the named package.
"Find the specified symbols" -- not "INTERN". Maybe the Symbolics
implementation does call INTERN, and you were thinking of that rather
than the DEFPACKAGE proposal?
-- JonL --
∂23-Sep-88 1946 CL-Cleanup-mailer Issue: STREAM-INFO (Version 4)
Received: from rice-chex.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Sep 88 19:45:07 PDT
Received: by rice-chex.ai.mit.edu; Fri, 23 Sep 88 22:44:51 EDT
Date: Fri, 23 Sep 88 22:44:51 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8809240244.AA03833@rice-chex.ai.mit.edu>
To: masinter.pa@xerox.com
In-Reply-To: masinter.pa@xerox.com's message of 23 Sep 88 13:47 PDT <880923-134724-1961@Xerox>
Subject: Issue: STREAM-INFO (Version 4)
Cc: gls@think.com, CL-Cleanup@sail.stanford.edu
Re letting the functions return rationals. That is fine with me.
I was just trying to think of efficiency in the programs that call
these functions.
Dick
∂24-Sep-88 1634 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88 16:34:20 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465093; Sat 24-Sep-88 19:33:03 EDT
Date: Sat, 24 Sep 88 19:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: CL-Cleanup@SAIL.Stanford.EDU
cc: JAR@AI.AI.MIT.EDU
In-Reply-To: <3270.8809182113@subnode.aiai.ed.ac.uk>,
<8809160203.AA07003@void>,
<871114-210454-3591@Xerox>
Message-ID: <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Jonathan Rees gave me a dump of a bunch of thinking he'd been doing
about PROCLAIM-LEXICAL and based on my understanding of that, I
decided to rewrite the existing proposals and revive this issue.
The focus and presentation is changed substantially -- I hope
for the better.
-----
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Status: For Internal Discussion
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which does
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that dynamic binding does DG lookup. That is, variables
declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect this declaration.
Test Case:
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 4))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
#2: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
Some compiler work would probably be needed. Some compilers may
have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
[I'll leave this open to discussion.]
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
∂24-Sep-88 1635 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 24 Sep 88 16:35:02 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA08465g; Sat, 24 Sep 88 15:32:48 PST
Received: by bhopal id AA13708g; Sat, 24 Sep 88 16:32:19 PDT
Date: Sat, 24 Sep 88 16:32:19 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809242332.AA13708@bhopal>
To: Gray@DSG.csc.ti.com
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: David N Gray's message of Wed, 21 Sep 88 11:50:27 CDT <2799852627-13866831@Kelvin>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
re: > (DEFUN FOO (X Y)
> (DECLARE (FLOAT X Y))
> (LET ((SUM (+ X Y)))
> (DECLARE (FLOAT SUM))
> (COND ((> SUM 3.0)
> (LOCALLY (DECLARE (FIXNUM X))
> ; X won't be used any more, so let's recycle its home...
> (SETQ X (TRUNCATE SUM))
> (+ (* X X) (* SUM Y))))
> (T
> (* X Y SUM)))))
Gag! This is an example of what we most definitely want to prohibit.
This is a highly misguided programming style and can be made meaningful
only if the compiler is prohibited from using specialized storage for
variables.
Right! You've put it very well. However, not everyone is aware of the
compiler techniques for "using specialized storage" to good advantage. I
doubt seriously whether the Symbolics lisp compiler would be concerned with
these questions, since it is reputed to ignore all type declarations anyway.
[I wonder if the CLOE treatment is significantly more advanced.]
Does the TI compiler do any of "these techniques"? Of course, Lucid
does something like PDP10 MacLisp did for certain numeric types, and
I'm sure that is why CLtL p158 has such an odd restriction on the
scope of type declarations -- i.e., to hinder just such gross programs
as the one you gagged upon above.
-- JonL -
∂24-Sep-88 1732 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Sep 88 17:32:05 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465122; Sat 24-Sep-88 20:29:20 EDT
Date: Sat, 24 Sep 88 20:29 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
To: JonL@Lucid.COM, Gray@DSG.CSC.TI.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM,
Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809242332.AA13708@bhopal>
Message-ID: <880924202915.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Fyi, I didn't mean to suggest that that program was good style. I was just
trying to answer Moon's "Is it necessary to be explicit?" query by
demonstrating that it was necessary.
∂26-Sep-88 1206 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:06:47 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09287g; Mon, 26 Sep 88 11:04:43 PST
Received: by blacksox id AA00135g; Mon, 26 Sep 88 12:02:11 pdt
Date: Mon, 26 Sep 88 12:02:11 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809261902.AA00135@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU
In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 19:32 EDT <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
Date: Sat, 24 Sep 88 19:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Test Case:
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 4))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Maybe I'm confused, but I thought this should be (1 2 (5 4)), since
the first reference to y is a lexical reference (LG). The setq of y
to 2 is global, but the binding of y to 4 is dynamic, and therefore
invisible to a lexical reference. This is an example of the case
where you stated "some searching may be necessary to find the global
cell in shallow bound implementations [unless dynamic binding has been
forbidden for that variable]" which is also illustrated in the second
example. Or did you intend that a lexically apparent dynamic binding
is also a lexical binding? That seems strange to me. It would imply
that a special binding is not equivalent to a corresponding PROGV, for
example.
∂26-Sep-88 1246 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 12:46:42 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465728; Mon 26-Sep-88 15:45:00 EDT
Date: Mon, 26 Sep 88 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: <8809261902.AA00135@blacksox>
Message-ID: <880926154450.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 12:02:11 pdt
From: Eric Benson <eb@lucid.com>
Date: Sat, 24 Sep 88 19:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Test Case:
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 4))
#'(lambda () (list x y))))))))
(tst) => (1 4 (5 4))
Maybe I'm confused, but I thought this should be (1 2 (5 4)) ...
You're not confused -- you're just polite. I was probably too burnt out
after putting this whole thing together to check the example as
thoroughly as I should have. It was merged and edited from one of the
numerous other drafts, and... Also, Jonathan's feedback to me said
explicitly that he didn't bother to check the example. I should have
known that meant trouble...
There's also the other `error' about the second y binding, which should
have been to 6, not to 4.
Does the following look ok to you?
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
By the way, completely as an aside:
If LEXICAL were defined to mean LDG search rather than LG search,
then the result would have been (1 4 (5 4)). That was what Moon's
proposal had suggested.
However, there's something very asymmetric and unsettling about
having DYNAMIC mean DG and LEXICAL mean LDG. One way to reach
harmony is LEXICAL=LG as we've proposed, but it occurs to me
as a curiosity that you could define DYNAMIC=DLG. I can't imagine
what the practical value of that would be, and it might be kinda
odd compiled, but it would keep from upsetting my sense of
symmetry and it would lead to the interesting result of (3 4 (5 4)),
which is marginally more intuitive than (1 4 (5 4)).
∂26-Sep-88 1412 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 14:12:27 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09428g; Mon, 26 Sep 88 13:10:21 PST
Received: by blacksox id AA00152g; Mon, 26 Sep 88 14:07:48 pdt
Date: Mon, 26 Sep 88 14:07:48 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809262107.AA00152@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: Kent M Pitman's message of Mon, 26 Sep 88 15:44 EDT <880926154450.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
Date: Mon, 26 Sep 88 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Does the following look ok to you?
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
I think that's (1 2 (5 6)).
∂26-Sep-88 1436 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 14:36:46 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465907; Mon 26-Sep-88 17:35:17 EDT
Date: Mon, 26 Sep 88 17:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: <8809262107.AA00152@blacksox>
Message-ID: <880926173510.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 14:07:48 pdt
From: Eric Benson <eb@lucid.com>
Date: Mon, 26 Sep 88 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Does the following look ok to you?
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
I think that's (1 2 (5 6)).
No, I'm not as tired this time, and I think I'm right ...
X gets bound lexically to 3 because X is [pervasively] proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively] proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively] proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively] proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not [special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically active Y=4
in a list which becomes third list element.
Make sense?
∂26-Sep-88 1455 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 14:55:00 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA09499g; Mon, 26 Sep 88 13:52:42 PST
Received: by blacksox id AA00173g; Mon, 26 Sep 88 14:50:10 pdt
Date: Mon, 26 Sep 88 14:50:10 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8809262150.AA00173@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: Kent M Pitman's message of Mon, 26 Sep 88 17:35 EDT <880926173510.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
Date: Mon, 26 Sep 88 17:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 14:07:48 pdt
From: Eric Benson <eb@lucid.com>
Date: Mon, 26 Sep 88 15:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Does the following look ok to you?
#1: (proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
I think that's (1 2 (5 6)).
No, I'm not as tired this time, and I think I'm right ...
X gets bound lexically to 3 because X is [pervasively] proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively] proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively] proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively] proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not [special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically active Y=4
in a list which becomes third list element.
Make sense?
Clear as mud! The point I was forgetting is that proclamations affect
references *and* bindings, while declarations only affect the bindings
to which they are attached (if any), and references *for which are
there are no intervening bindings*. There's still no such thing as a
pervasive declaration, either for SPECIAL or LEXICAL.
Do you want to make LEXICAL the default for otherwise unspecified
references? It still might be a good idea to warn about the absence
of any declaration.
∂26-Sep-88 1523 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 15:23:12 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 465961; Mon 26-Sep-88 18:21:32 EDT
Date: Mon, 26 Sep 88 18:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: eb@lucid.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: <8809262150.AA00173@blacksox>
Message-ID: <880926182124.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 14:50:10 pdt
From: Eric Benson <eb@lucid.com>
... Do you want to make LEXICAL the default for otherwise unspecified
references? It still might be a good idea to warn about the absence
of any declaration.
This proposal doesn't suggest it.
I thought hard about it and decided there was really no reason to.
After all, you still need to initialize the variable you'll be
closing over, so you can do the proclamation at the same time.
The missing component which does need to be followed up on if this
gets approved is how we declare these variables. People will want
lexical analogs of DEFVAR and DEFPARAMETER or perhaps some extended
syntax to these which allows you to designate that the proclamation
should be LEXICAL instead of DYNAMIC. I suspect that this issue will
be a subject of much controversy as well, so I wanted to make sure it
was fully separated in order to stave off the multiplicative effects
of doing too many controversial things at once.
∂26-Sep-88 1719 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 17:19:11 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09621g; Mon, 26 Sep 88 16:17:13 PST
Received: by bhopal id AA02429g; Mon, 26 Sep 88 17:16:45 PDT
Date: Mon, 26 Sep 88 17:16:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270016.AA02429@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Sep 88 01:19 PDT <880923-011851-3969@Xerox>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (split from PACKAGE-CLUTTER)
re: But then I get to issues like this, where if you write a simple program
that says
(in-package "FROB")
(defun draw-line (x y) ...)
that when they go to port it to Vendor y, they find out that their simple
program crashes the graphics package because draw-line now has the wrong
arguments. "I meant FROB:DRAW-LINE, not some LU-GRAPHICS:DRAW-LINE."?
First, the 'in-package' statement doesn't necessarily define the package,
and hence one can't assume a default :use list.
Probably one of the more confusing bugs that users fall into is having two
slightly different package creation forms in two different files belonging
to the same package. Say:
(in-package "FROB" :use '(:lisp :holistics))
in the first file, and
(in-package "FROB")
in the second. IN-PACKAGE as currently defined is not supposed to "warn"
you if the package doesn't already exist, or if it exists with components
different from what you specified. You simply lose if you process the
second file first.
[Incidentally, this brings up the fact that the only utility of a DEFPACKAGE
proposal is that it tends to focus on one place, and one place only, where a
package can be defined. The proposal adds absolutely no functionality not
currently available with the "7 extremely randoms" and 'eval-when' -- it
merely focuses the user's attention.]
Second -- as mentioned in prior mail -- those currently porting from
vendor to vendor will *never* allow the :use argument to MAKE-PACKAGE to
be defaulted. This good practice could be encouraged by removing from the
standard any requirement about what the default will be. Those involved in
*converting* code written for one vendor's Lisp to run in another vendor's
face a different problem, namely how to reconcile the names they have used
with those "available" under the other vendor [frequently, they even
aren't concerned with being super-portable, especially when it comes
to windows and graphics capabilities, since there is no standard yet
in those realms.]
The references to the portability of C programs, and to the difficulty
of porting CL programs, seems to be completely ignorant of the horrible
problem in porting between one vendor's Unix library and another's. As
if C were merely a "language" with no library support needed! But in fact
CLtL is not only a specification for the hard-core language, but that also
for the greater part of the runtime-library.
At any rate, portabililty is not sacrificed in the least when it is defined
as "portable programs must supply the :use argument to MAKE-PACKAGE and
friends."
-- JonL --
∂26-Sep-88 1724 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 17:23:45 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09628g; Mon, 26 Sep 88 16:21:48 PST
Received: by bhopal id AA02450g; Mon, 26 Sep 88 17:21:20 PDT
Date: Mon, 26 Sep 88 17:21:20 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270021.AA02450@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Sep 88 01:15 PDT <880923-011503-3968@Xerox>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
re: Current Practice:
. . .
Symbolics Genera currently has exactly the set of symbols on it which is
prescribed by CLtL.
Lucid has exactly such set in the Lisp package. In fact, several iterations
between Dan Weinreb, Penny (last name?), and myself were required during
the summer of 1986 to get it right.
-- JonL --
∂26-Sep-88 1739 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 17:39:33 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09634g; Mon, 26 Sep 88 16:37:37 PST
Received: by bhopal id AA02525g; Mon, 26 Sep 88 17:37:09 PDT
Date: Mon, 26 Sep 88 17:37:09 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270037.AA02525@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Sep 88 02:13 PDT <880923-021329-3994@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 3)
re: Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
(CONSes, bit-vectors, strings, pathnames). EQUAL uses EQL
for numbers and EQ for all other types.
This is definitely NOT the status quo. You are describing EQUAL, but
definitely not EQUALP. CLtL p81 says of EQUALP: "Objects that have
components are EQUALP if they are of the same type and corresponding
components are EQUALP."
Every implementation I've ever seen has in fact implemented EQUALP so
that it "descends" e.g. defstruct instances (among other things).
-- JonL --
∂26-Sep-88 1756 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 17:56:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466064; Mon 26-Sep-88 20:54:10 EDT
Date: Mon, 26 Sep 88 20:54 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809270021.AA02450@bhopal>
Message-ID: <19880927005412.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 26 Sep 88 17:21:20 PDT
From: Jon L White <jonl@lucid.com>
re: Current Practice:
. . .
Symbolics Genera currently has exactly the set of symbols on it which is
prescribed by CLtL.
Lucid has exactly such set in the Lisp package. In fact, several iterations
between Dan Weinreb, Penny (last name?),
Parkinson.
and myself were required during
the summer of 1986 to get it right.
Agreed. If I recall what I heard about this, the problem is that it's difficult
to extract from CLtL the set of symbols that are specified to be in the Lisp
package, since a few of them are not in the index.
∂26-Sep-88 1934 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 19:33:54 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA09696g; Mon, 26 Sep 88 18:30:59 PST
Received: by bhopal id AA02793g; Mon, 26 Sep 88 19:30:32 PDT
Date: Mon, 26 Sep 88 19:30:32 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270230.AA02793@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Gray@DSG.CSC.TI.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Sat, 24 Sep 88 20:29 EDT <880924202915.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 1)
re: Fyi, I didn't mean to suggest that that program was good style. I was just
trying to answer Moon's "Is it necessary to be explicit?" query by
demonstrating that it was necessary.
Understood. I liked Gray's phraseology re "specialized storage". Some
commentary alluding to that ought to be in the proposal; that would help
justify the restriction against this "explicit" style.
-- JonL --
∂26-Sep-88 2043 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 20:42:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466117; Mon 26-Sep-88 23:41:34 EDT
Date: Mon, 26 Sep 88 23:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880707161211.9.KMP@RIO-DE-JANEIRO.SCRC.Symbolics.COM>
Message-ID: <19880927034132.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY even though I rarely
favor incompatible changes. As JonL pointed out in a recent message,
the fact that Common Lisp encourages users to replicate their package
definitions in several places (several calls to IN-PACKAGE) leads to
errors that are difficult to diagnose and correct.
Even if DEFPACKAGE is not adopted, I still favor
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY, in spite of the proposal's
claim to depend on DEFPACKAGE; MAKE-PACKAGE could be used instead.
∂26-Sep-88 2103 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 21:03:18 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466128; Tue 27-Sep-88 00:02:00 EDT
Date: Tue, 27 Sep 88 00:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880923-011503-3968@Xerox>
Message-ID: <19880927040206.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Those symbols with function, variable, macro, setf, constant definitions
or uses as properties or tokens may have no other additional definitions
other than those specified.
I cannot support this as stated. The word "definitions" is not defined.
It is unclear why this restriction applies only to a subset of the symbols
exported by the LISP package instead of all those symbols. I'm not sure
the generalization from SPECIAL proclamations (the original complaint)
to all "definitions" is justified, and I'm sure I don't understand all
of its ramifications.
If that paragraph were changed to something like the following I think
I could support the proposal. I'd want to check the rest of the details
a bit more carefully.
Implementations are not permitted to proclaim SPECIAL additional
external symbols of the LISP package beyond the symbols defined by
Common Lisp to be variables or constants.
I think the next specification of Common Lisp needs to contain a
comprehensive list of every symbol exported by the LISP package and
the characteristics of that symbol.
∂26-Sep-88 2106 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 21:06:44 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466133; Tue 27-Sep-88 00:04:47 EDT
Date: Tue, 27 Sep 88 00:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 2)
To: Jon L White <jonl@lucid.com>
cc: masinter.pa@Xerox.COM, CL-Cleanup@Sail.stanford.edu
In-Reply-To: <8809240002.AA11135@bhopal>
Message-ID: <19880927040452.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I remain confused by the discussion. Rather than going around and around
in circles, why don't you just write up the proposal your way, leaving out
arguments comparing it with the previous proposal, and then I will either
criticize it constructively or accede to it.
∂26-Sep-88 2139 CL-Cleanup-mailer Issue: STREAM-INFO (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 26 Sep 88 21:38:51 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466144; Tue 27-Sep-88 00:37:24 EDT
Date: Tue, 27 Sep 88 00:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: STREAM-INFO (Version 5)
To: Richard C. Waters <dick@wheaties.ai.mit.edu>, CL-Cleanup@sail.stanford.edu
In-Reply-To: <8809231612.AA00588@rice-chex.ai.mit.edu>
Message-ID: <19880927043729.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve STREAM-INFO:ONE-DIMENSIONAL-FUNCTIONS in version 5.
Your property 9 appears to have been garbled by an editing error.
∂26-Sep-88 2154 CL-Cleanup-mailer proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 21:54:38 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00202g; Mon, 26 Sep 88 20:52:37 PST
Received: by bhopal id AA03126g; Mon, 26 Sep 88 21:52:09 PDT
Date: Mon, 26 Sep 88 21:52:09 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270452.AA03126@bhopal>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 19 Sep 88 14:06:15 MDT <8809192006.AA00963@defun.utah.edu>
Subject: proposal LOAD-TIME-EVAL:REVISED-NEW-SPECIAL-FORM
Of the numerous proposals of this ilk, this one seems to me to be the one
most workable.
Following our charter, we should look to Interlisp and see how experience
has fared with its function LOADTIMECONSTANT [maybe never documented?].
Its semantics were, coincidentally, essentially the same as those you have
spelled out for LOAD-TIME-EVAL. [By the way, shouldn't the Interlisp
precedent bias us towards the name LOAD-TIME-CONSTANT rather than towards
LOAD-TIME--EVAL?].
However, a more serious issue seems to have gotten lost in all the flaming.
At Lucid, we all seem to favor flushing #,. Who really wants it? At best,
when someone previously suggested flushing #, I remember an efficiency
argument being invoked, but not being _demonstrated_.
There is a serious flaw in the design of #, and for this reason alone
it should be flushed [explication of the "flaw" is further below.] The
burden of _proof_ to show that any reasonable program is seriously
hampered without it is on those who invoke the argument. As Gabriel
would say of benchmarking, no raw numbers without theory to explain why,
and certainly no speculation without hard numbers.
Where are the numbers which prove an inefficiency so grave as to cause
us to tolerate this inherently flawed and misleading construct #,?
The "grave flaw" centers around the common misconception that you
are either:
(1) reading the source code, for interpretation -- EVAL situation
(2) reading it for compilation to a file -- COMPILE situation
(3) loading the compiled version of the file -- LOAD situation
that is, one and only one of the three situations applies. But as Kent's
little trivial example showed:
(EVAL-WHEN (EVAL COMPILE LOAD)
(DEFUN FOO (X) #,`(X ,(SQRT 3))))
you may be reading a piece of code for *** two *** of the situations at
one time. You are both EVAL'ing and COMPILE'ing a single solitary form
at essentially "one and the same time". [Early versions of PCL tried to
use some such trick, and lost badly.]
The whole idea of the "magic token" is that at read-time you can somehow
inspect either the dynamic or lexical environment, and decide with of the
three situations is relevant. But you can't; you can only know which
situation is relevant at actual processing time -- not at read time (and
of course a special form has access to the lexical environment). Sandra
put it quite well when countering a proposal to make the LOAD-TIME-EVAL
thing be a function instead of a special form:
Date: Wed, 21 Sep 88 15:05:28 MDT
Subject: Re: Issue: LOAD-TIME-EVAL (Version 6)
. . .
there a[re] more situations in which code is processed than simply
interpretation and compilation. It is not an either/or situation. A
person here at the UofU, for example, has been working on a portable
type inference preprocessor. It reads in code, decorates it with lots
of type declarations, and writes it out to another file which may then
either be loaded interpretively or compiled with COMPILE-FILE. . . .
The implications of these theoretical arguments are not always easy to
follow, so I have reproduced an example file below that helps one see
just how the screw-up occurs. Every implementation I've tried this file
in, when the source is loaded, "does the right thing". But when it is
compiled, they all leave the "magic tokens" in the source code for the
function 'expose'; so the value of 'foo', after compilation, has these
tokens in it rather than the desired structure ((COMPILE A) (COMPILE B)).
Correspondingly, the value of 'bar' -- the 'exposure-normality' of 'foo'
-- is ABNORMAL.
Worse yet, because the definition of 'normally-exposed-p' is a macro that
gets "snapped" at compile time, the error is propagated to the runtime
setting of 'bar'. Namely, when the compiled file is loaded, 'foo' has
the right value -- ((LOAD A) (LOAD B)) -- but 'bar' wrongly says that
the 'exposure-normality' state is ABNORMAL. [Well, one implementation
got the value of 'foo' wrong too, but, hey, what the heck.]
Take this example and try it. Look at FOO and BAR after each pass.
You'll dislike it! Flush #,.
-- JonL --
;;;--------------------------------------------------------------------------
(in-package "USER")
;;; Clean the slate, in case this isn't "first time" processing
(eval-when (eval compile load)
(fmakunbound 'expose)
(fmakunbound 'exposure-normality)
(proclaim '(special markers))
)
;;; Use different marker depending on which situation is relevant.
(eval-when (eval)
(setq markers '((eval a) (eval b) (eval c)))
)
(eval-when (compile)
(setq markers '((compile a) (compile b) (compile c)))
)
(eval-when (load)
(setq markers '((load a) (load b) (load c)))
)
(eval-when (eval compile load)
(defun expose ()
`(#,(pop markers) #,(pop markers)))
(defmacro exposure-normality ()
(if (member (car (expose))
'((eval a) (compile a) (load a))
:test #'equal)
`'normal
`'abnormal))
)
(eval-when (eval compile load)
(defparameter foo (expose))
(defparameter bar (exposure-normality))
)
;;;--------------------------------------------------------------------------
∂26-Sep-88 2302 CL-Cleanup-mailer Issue HASH-TABLE-TESTS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 26 Sep 88 23:02:07 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00238g; Mon, 26 Sep 88 22:00:09 PST
Received: by bhopal id AA03266g; Mon, 26 Sep 88 22:59:40 PDT
Date: Mon, 26 Sep 88 22:59:40 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809270559.AA03266@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue HASH-TABLE-TESTS
Issue: HASH-TABLE-TESTS
References: CLtL, p382 (third paragraph), and p383
Issue EQUAL-STRUCTURE
Issue: CONTAGION-ON-NUMERICAL-COMPARISONS
Category: Addition
Edit history: 26-Sep-88 Version 1 by JonL
Problem Description:
A great many users try to coalesce two equivalent defstruct instances,
or two equivalent pointer arrays, using hash tables; but they are rudely
awakened when they find out that EQUAL is not an appropriate test for
this case, and that there is no :test argument to MAKE-HASH-TABLE which
will "hash on non-tree structures".
Proposal: HASH-TABLE-TESTS:ADD-EQUALP
With the advent of the issue CONTAGION-ON-NUMERICAL-COMPARISONS, we
can expect EQUALP to be a true equivalence function, and thus a suitable
candidate for the :test function to MAKE-HASH-TABLE. Hash-tables will
come in four kinds, the difference being whether the keys are compared
with EQ, EQL, EQUAL, or EQUALP.
Examples:
> (defstruct foo a b c)
FOO
> (setq x (make-foo :a 1 :b 'b :c '(1 . 2))
x-copy (make-foo :a 1 :b 'b :c '(1 . 2)))
#S(FOO A 1 B B C (1 . 2))
> (setq y #(1 B (1 . 2))
y-copy (copy-seq y))
#(1 B (1 . 2))
> (setq ht-equal (make-hash-table :test 'equal)
ht-equalp (make-hash-table :test 'equalp))
#<Hash-Table BB1F7B>
> (progn (setf (gethash x ht-equal) t) (setf (gethash x ht-equalp) t)
(setf (gethash y ht-equal) t) (setf (gethash y ht-equalp) t))
T
> (gethash x-copy ht-equal)
NIL
NIL
> (gethash x-copy ht-equalp)
T
T
> (gethash y-copy ht-equal)
NIL
NIL
> (gethash (copy-seq y) ht-equalp)
T
T
>
Rationale:
Implementing hash-tables efficiently is not an easy task; it makes more
sense for this to be standardly available (implemented by the wizards at
the Lisp vendor companies) than for individual programmers to keep trying
to re-invent this obscure part of technology.
Current Practice:
Lucid's release 3.0 implements this proposal [some 2.1-level release
supported it "provisionally"]. Symbolics implementation is reputed
to be robust enough to implement this proposal trivially.
Cost to Implementors:
Moderate. Implementors have already dealt with EQUAL; the only tricky
part will be ensuring the implication:
"If 'a' is EQUALP to 'b', then 'a' and 'b' must lie in the
same collision chain in any given EQUALP hash table"
It has been suggested that merely linear searching a table is an acceptable
implementation technique for CL's hash-tables [although no serious
implementation limits itself thus] and that such tables have no "collision
chains"; but in fact, this is the degenerate case wherein all entries are
in the same collision chain, so the implication is trivially satisfied.
Some persons prefer to say that the "reprobe sequence will be the same for
the two items", rather than using the term "collision chain"; the meaning
is the same.
Cost to Users:
None. This is an entirely upwards-compatible addition.
Cost of non-adoption:
Continuing bug reports from CL vendors' customers about why "hashing
doesn't work" when said customer tries entering pointer-containing objects
other than cons cells into hash tables. Continuing delay in same
customers work until they figure out a new strategy for identifying
equivalent structures. More difficulty in debugging their alternatives.
Benefits:
Addresses one aspect of the difficult equivalence problem. Makes
hash tables usable with the major, remaining equivalence predicate
of CL. Also as a "side effect", permits case-insensitive hashing
on strings [tables of type EQUAL are case-sensitive on strings];
another "side effect" is the abililty to use the CL numeric comparison
"=" for numbers [tables of type EQUAL use EQL on numbers].
Aesthetics:
Reduces the discontinuity between basic equivalence functions and those
usable as equivalence relations in hash-tables.
Discussion:
With the rejection of all the issues related to EQUAL-STRUCTURE, there is
little or no hope that EQUAL will be "beefed up" to meet the expectations
of so many of the user community on compound structures. If one wants
a hash-table with a :test function that has fewer equivalence classes
(i.e., does more "coalescing"), then there is no alternative now except
to use the function EQUALP.
∂27-Sep-88 0504 CL-Cleanup-mailer Moon@stony-brook.scrc.symbolics.com
Received: from rice-chex.ai.mit.edu ([128.52.38.46]) by SAIL.Stanford.EDU with TCP; 27 Sep 88 05:04:40 PDT
Received: by rice-chex.ai.mit.edu; Tue, 27 Sep 88 08:04:30 EDT
Date: Tue, 27 Sep 88 08:04:30 EDT
From: dick@wheaties.ai.mit.edu (Richard C. Waters)
Message-Id: <8809271204.AA11669@rice-chex.ai.mit.edu>
To: CL-Cleanup@sail.stanford.edu
Subject: Moon@stony-brook.scrc.symbolics.com
Property 9 should read as follows.
9- For all X,Z (= (printed-width X S)
(progn (write-string Z S) (printed-width X S)))
I.E. the printed-width of a string of simple characters does not
vary based on line position.
More thoughts on whether printed-width etc. should be able to return
rational numbers instead of just integers. This is certainly logical,
however, it seems to me to be unreasonably in the inefficiency it forces
on the users of these functions. Note that in order to get the units right,
you would not have to figure out the least common denominator in the widths
of the characters in a font. It should be sufficient to simply pick the
resolution of the output device (e.g., 72 pixels per inch or whatever).
Dick
∂27-Sep-88 0728 CL-Cleanup-mailer Re: Moon@stony-brook.scrc.symbolics.com
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 07:28:10 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 27 Sep 88 10:24:16 EDT
To: dick@wheaties.ai.mit.edu (Richard C. Waters)
cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Moon@stony-brook.scrc.symbolics.com
In-reply-to: Your message of Tue, 27 Sep 88 08:04:30 -0400.
<8809271204.AA11669@rice-chex.ai.mit.edu>
Date: Tue, 27 Sep 88 10:23:46 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
My vote is that we stick with integers, more as a matter of user-sanity
than on grounds of efficiency. The implementation can pick quantum units
that are appropriately small.
-- Scott
∂27-Sep-88 0927 CL-Cleanup-mailer Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88 09:27:04 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466341; Tue 27-Sep-88 12:25:51 EDT
Date: Tue, 27 Sep 88 12:25 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: IN-PACKAGE-FUNCTIONALITY (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19880927034132.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880927122539.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Mon, 26 Sep 88 23:41 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... Even if DEFPACKAGE is not adopted, I still favor
IN-PACKAGE-FUNCTIONALITY:SELECT-ONLY, in spite of the proposal's
claim to depend on DEFPACKAGE; MAKE-PACKAGE could be used instead.
Well, one issue is that we need something that will be processed at
compile time. Replacing
(IN-PACKAGE 'FOO) ;Current semantics
with
(MAKE-PACKAGE 'FOO)
(IN-PACKAGE 'FOO) ;New semantics
will not do because (at least in Genera and I bet in other implementations
as well), MAKE-PACKAGE signals an error if the package already exists.
If you write:
(UNLESS (FIND-PACKAGE 'FOO) (MAKE-PACKAGE 'FOO))
(IN-PACKAGE 'FOO) ;New semantics
you lose because the IF isn't processed at compile time and the IN-PACKAGE
will say no such package at compile time. You have to write
(EVAL-WHEN (EVAL COMPILE LOAD)
(UNLESS (FIND-PACKAGE 'FOO) (MAKE-PACKAGE 'FOO)))
(IN-PACKAGE 'FOO)
which I find a little on the ugly side.
Technically you're right that MAKE-PACKAGE is enough, but stylistically
IN-PACKAGE was convenient because it was so much less obscure. If DEFPACKAGE
doesn't come in, some might think we're causing them a hassle. I dunno...
For now I think I'll just cross my fingers for DEFPACKAGE being adopted and
hope this issue will become moot.
∂27-Sep-88 0936 CL-Cleanup-mailer Issue HASH-TABLE-TESTS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88 09:36:37 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466350; Tue 27-Sep-88 12:35:19 EDT
Date: Tue, 27 Sep 88 12:35 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue HASH-TABLE-TESTS (Version 1)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809270559.AA03266@bhopal>
Message-ID: <19880927163514.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
HASH-TABLE-TESTS:ADD-EQUALP is okay with me. It needs to be made
very clear that this proposal cannot pass unless the proposal for
CONTAGION-ON-NUMERICAL-COMPARISONS passes.
∂27-Sep-88 1006 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88 10:06:22 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466365; Tue 27-Sep-88 13:04:57 EDT
Date: Tue, 27 Sep 88 13:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19880927040206.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880927130442.2.KMP@GRYPHON.SCRC.Symbolics.COM>
I'm concerned about things mentioned in the spec as functions
which turn out to also be variables and vice versa. Ditto for
types. If either the system or any user application defines such,
it gets forced down everyone's throat and potentially clobbers
someone else's supposedly private application. It also reduces
the level of error checking provided to users who think they're
getting strict CLtL by just using things on LISP.
How would you feel about something like the following. It's
broader, but still tries to be specific...
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
∂27-Sep-88 1039 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88 10:39:08 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466386; Tue 27-Sep-88 13:37:51 EDT
Date: Tue, 27 Sep 88 13:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU
In-Reply-To: <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880927173749.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think it would be good to do something resembling this, but there is a
serious defect in your proposal, namely that the cost to implementors is
grossly understated ("some compiler work would probably be needed"
indeed!). In fact I have been unable to think of any way to implement
this proposal in a fully shallow-bound system. Either references to the
D environment, or references to the G environment that did not first
search the D environment, would have to be implemented with a
deep-binding style environment search. Your proposal gives no hint of
this efficiency cost. Maybe there's a clever implementation technique I
haven't thought of; if so I wish someone would tell me.
The KMP/EB discussion suggests that the semantics of the proposal are
very confusing even to experts, although perhaps it's just unfamiliar.
∂27-Sep-88 1055 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 27 Sep 88 10:54:54 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466400; Tue 27-Sep-88 13:53:37 EDT
Date: Tue, 27 Sep 88 13:53 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: <19880927173749.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <880927135318.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 13:37 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... the cost to implementors is grossly understated ("some compiler work
would probably be needed" indeed!). ...
I had written "a fair amount" in v6 and Rees seemed to think that was
overstating things. I'm content to add that back in, or something stronger. :-)
In fact I have been unable to think of any way to implement this proposal
in a fully shallow-bound system...
Rees suggested (and I was going to add in the next revision), that you could
mark the global cell with a bit saying whether it had been re-bound in the
interim.
The only place this cost comes up at all is when a free lexical is referenced.
Bound lexicals incur no overhead. As such, only new code can be affected and
a slowdown cannot be perceived because there is nothing to compare timings with.
Also, I would expect that in by far the majority of situations, variables
declared lexical will not be used dynamically and vice versa. As such, the
one-bit mark above (assuming an implementation has a place to put that bit
without increasing the size of symbols by a whole slot-width) will nearly
always allow you to avoid the search because the valid bit will nearly always
be set (I (very unscientifically) claim).
Your proposal gives no hint of this efficiency cost.
Next draft will fix that.
Maybe there's a clever implementation technique I haven't thought of;
if so I wish someone would tell me.
You can tell me if the above seems clever enough.
The KMP/EB discussion suggests that the semantics of the proposal are
very confusing even to experts, although perhaps it's just unfamiliar.
That example would not be intuitive no matter -what- the semantics.
It's an example you created yourself in order to demonstrate the edge
effects concisely but shouldn't be taken to be model code. It does ok
but isn't something to be taken as model code. In practice, programs
use more mnemonic names, don't bind variables and then throw the values
away, don't bind a lexical variable and then disable references to the
binding by funny local declarations, etc. In the next draft, I'll put
the other example first so that people can practice on an intuitive case
before doing the extra credit problem.
∂27-Sep-88 1724 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88 17:24:40 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00516g; Tue, 27 Sep 88 16:22:38 PST
Received: by bhopal id AA05760g; Tue, 27 Sep 88 17:22:11 PDT
Date: Tue, 27 Sep 88 17:22:11 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809280022.AA05760@bhopal>
To: masinter.pa@Xerox.COM
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 22 Sep 88 22:25 PDT <880922-222553-3848@Xerox>
Subject: Issue: DECLARE-TYPE-FREE (Version 4)
The comment about Lucid's warning messages made me wonder -- it *isn't*
invoked by the sample code in the problem description. Consequently,
I've amended the statement of the problem in what is intended to be a
very friendly way (I also laid more of the "blame" at the clear
proscription in CLtL p158, rather than on the percentage of people who
think it "invalid".) And I added "setf" to the "setq" part of the
proposal -- probably one should understand the unqualified phrase
"variable references" to mean "variable updating references" as well
as "variable accessing references".
Looking over the past mail, I saw a few more loose tidbits that needed
to be cleaned up; in particular the msg:
Date: Tue, 20 Sep 88 19:04:46 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
suggested the need for a re-wording of the "Rationale" and "Benefits"
section, and I extend this to the "Esthetics" section too.
Finally, I added a bit to the discussion section, mostly reflecting
the current state regarding "compilers" that use specialized-storage
for type-declared variables (i.e., Lucid's "Production" compiler).
By the bye, I'm not happy with the part that allows nested type specifiers
to be overly general. I'd prefer that the inner ones be subtypes of the
outter ones, so that the program:
(locally (declare (type x fixnum))
(locally (declare (type x (or bit package)))
(setq x 1)))
would be "in error"; i.e., inner types should be more sensitive to the
outter constraints. But this would not be a "friendly amendment" or
minor cleanup; so I haven't done anything about it.
-- JonL --
!
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or setf.
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
None, it is valid to ignore type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
∂27-Sep-88 1928 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 27 Sep 88 19:28:35 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 27 Sep 88 22:24:27 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
In-reply-to: Your message of Tue, 27 Sep 88 13:04:00 -0400.
<880927130442.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 22:23:54 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
I don't know what "variable definitions" means.
Does this mean that I, as a user, am not allowed to use symbols such as
LIST, MEMBER, or SYMBOL as a lexical variable in my own protable code? If
so, I am very strongly opposed to this. The conversion cost would be very
high, and I don't see any safety issue that would force us to restrict the
user in this way. If that is not the intended meaning, perhaps some
clearer wording is needed.
I'd go along with the other cases.
-- Scott
∂27-Sep-88 2256 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88 22:56:45 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00600g; Tue, 27 Sep 88 21:41:44 PST
Site:
Received: by bhopal id AA06405g; Tue, 27 Sep 88 22:41:16 PDT
Date: Tue, 27 Sep 88 22:41:16 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809280541.AA06405@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 27 Sep 88 00:04 EDT <19880927040452.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 3)
re: ... why don't you just write up the proposal your way, leaving out
arguments comparing it with the previous proposal, and then I will
either criticize it constructively or accede to it.
Well, ok, but all I really wanted to do was to get consensus on the one
point of removing :IMPORT and :SHADOWING-IMPORT.
Here is your version 2 from 23-Mar-88 with that deletion, and with the
following emmendations, all of which are minor except for (3):
(1) "symbol" --> "symbol-name" in numerous places, as per your mail
message of "Date: Fri, 20 May 88 22:12 EDT"; also added appropriate
commentary about depending only the "name", not the symbol.
(2) Specify that :IMPORT-FROM (and :SHADOWING-IMPORT-FROM) signals an
error if any of the specified symbols do not already exist in the
"from" package.
(3) Explicitly permit EXPORT to work after the other options, so that
it can apply to imported and inherited symbols, as well as to
absolutly fresh ones; this is new -- I hope you can agree to it, or
give constructive criticism.
(4) Added, and updated, references to Issues IN-PACKAGE-FUNCTIONALITY
and PROCLAIM-ETC-IN-COMPILE-FILE; also added my "support" for the
former into the Discussion section.
(5) Added an alternate form under Examples; added "canonicalization"
comment to Discussion.
(6) Re-order the presentation of the options to accord with a revised
order for the "7 Extremely Randoms" of CLtL p191 [not very important].
-- JonL --
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Mar-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and give Common Lisp a bad name.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Also expand MAKE-PACKAGE (and IN-PACKAGE, unless the cleanup Issue
IN-PACKAGE-FUNCTIONALITY is adopted) to take all the same keyword
arguments as DEFPACKAGE, for consistency.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
'package-name' is a symbol or a string; if a symbol, only its name
matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
Standard options for DEFPACKAGE are listed below. Additional options
might be present in an implementation, and each implementation must
signal an error if an option not recognized by that implementation is
present. Additional implementation-dependent options might take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
Inherit from the specified packages.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined, and
place them on the shadowing symbols list. Each 'symbol-name'
argument must be either a string or a symbol. If given as a
symbol, only its name is used; and in this case the shadowing
symbol entered into the package being defined is definitely not
the one given as argument, but rather a symbol of the same name
freshly created as a shadow in the package.
(:SHADOWING-IMPORT-FROM {(package-name {symbol-name}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol}*)
Find the specified symbols in the specified packages and import
them into the package being defined, and place them on the
shadowing symbols list. Each 'symbol-name' argument must be
either a string or a symbol. If given as a symbol, only its
name is used; and in this case, the symbol that is imported is
not necessarily the one given as an argument, but rather the symbol
of that name accessible in the "from" package. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible for
one of the names in its corresponding "from" package. The second
syntax is simply a convenient abbreviation when only one package
is specified.
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified packages and import
them into the package being defined. Each 'symbol-name' argument
must be either a string or a symbol. If given as a symbol, only
its name is used; and in this case, the symbol that is imported is
not necessarily the one given as argument, but rather the symbol
of that name accessible in the "from" package. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible for
one of the names in its corresponding "from" package. The second
syntax is simply a convenient abbreviation when only one package
is specified.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Each 'symbol-name' argument must be either a string or a symbol.
If given as a symbol, only its name is used; and in this case,
the symbol that is made external in the defined package is not
necessarily the one given as an argument, but rather a symbol of
that name freshly interned in the package being defined. Note an
interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
intern'ing will merely access an already imported symbol.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
The collection of symbol-name arguments given to the options :SHADOW,
:IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be disjoint; an error
is signalled otherwise. In a chronological sense, the :EXPORT may be
thought of as ocurring last so that it can make reference to inherited
or imported symbols already created by the other three options.
Examples:
;;; Play it super-safe, and use only strings as names; do not even assume
;;; assume that the package it is read in to "uses" LISP; do *not* create
;;; any symbols whatsoever in the package that it is read in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, using symbols rather than strings as names; expects
;;; to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(DEFPACKAGE MY-PACKAGE
(:NICKNAMES MYPKG :MY-PKG)
(:USE LISP)
(:SHADOW CAR :CDR #:CONS)
)
Rationale:
See first paragraph of Proposal section.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Should be small as the macro can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
No cost, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
Moon (and JonL and KMP) thinks this is a reasonable idea, and is the
subject of a separate proposal.
The macroexpansion of DEFPACKAGE should be permitted to canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
∂27-Sep-88 2318 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (?)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88 23:18:12 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00613g; Tue, 27 Sep 88 22:16:09 PST
Received: by bhopal id AA06493g; Tue, 27 Sep 88 23:15:16 PDT
Date: Tue, 27 Sep 88 23:15:16 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809280615.AA06493@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 27 Sep 88 13:04 EDT <880927130442.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (?)
re: How would you feel about something like the following. It's
broader, but still tries to be specific...
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
Uncomfortable with the part that says that user's can't use LISP
package symbols for names. I very much agree that vendors (and VAR's
like Intellicorp!!!) should not have any definitions "hanging off"
LISP symbols other than the mandated ones. However, this may spell
a bit of work for implementations like VAXLISP that use the property
list for compiler internals.
In fact, at one point in time, some of Lucid's window tool kit
implementation "leaked over" into the Lisp package; the symbol
POSITION had some random defstruct about it; and when a user
tried his own defstruct, he was overly surprised to see that
the system depended on that one [the windows package simply
forgot to shadow POSITION].
Jim Boyce here at Lucid has taken an interest in this matter; I'd
like to get him to write out a full critique, and possibly a new
proposal. In particular, he points out that we should also constrain
implementors from depending on the *lack* of any additional
definitions other than the CLtL ones. Can you imagine a vendor
selling a Lisp that _dies_ as soon as you do (defvar list 3)?
-- JonL --
∂27-Sep-88 2359 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 27 Sep 88 23:59:19 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00631g; Tue, 27 Sep 88 22:56:50 PST
Received: by bhopal id AA06564g; Tue, 27 Sep 88 23:56:21 PDT
Date: Tue, 27 Sep 88 23:56:21 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809280656.AA06564@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU,
JAR@AI.AI.MIT.EDU
In-Reply-To: David A. Moon's message of Tue, 27 Sep 88 13:37 EDT <19880927173749.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
re: The KMP/EB discussion suggests that the semantics of the proposal are
very confusing even to experts, although perhaps it's just unfamiliar.
I agree. This might be something we shouldn't even think about standard-
izing until some implementor/vendor takes the plunge in a trial balloon,
presumably based on his belief that these semantics are immensely worthwhile
to Common Lisp users -- so important in fact that he's willing to "run ahead"
of the X3J13 committee and use it for a couple of years. Otherwise, without
some practical evidence that there is overwhelming gain to be had, I fear
we could commit ourselves for an enormous implementational headache purely
because it "seemed like a nice idea at the time".
Yes, I remember, I was mildly in favor of the original proposal; but that
was a year and a half ago, and I expected a GLOBAL declaration to mean that
it would be illegal to special-bind that name (hence you could depend on
that name *not* being in the D environment). Had somebody implemented
something like it for their Lisp back then, we might have had results to
talk about now.
Incidentally, Lucid has done a deep-binding implementation -- for QLISP.
Needless to say, it wasn't an overnight project; and the performance
results could be questioned (or else, we could just commit more good
money after bad to keep tweaking it indefinitely). Well, anyway, QLISP
*is* a research project.
I think it would be better to drop the notion of dynamic bindings --
SPECIAL variables -- altogether, than to try to graft a hybrid notion
on top of Common Lisp. There are quite a few folks who really would
like to flush special variables; but that's an issue guaranteed to
cleave the community down the middle.
-- JonL --
∂28-Sep-88 0852 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 08:52:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 466976; Wed 28-Sep-88 11:22:12 EDT
Date: Wed, 28 Sep 88 11:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU, JAR@AI.AI.MIT.EDU
In-Reply-To: <880924193252.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19880928152208.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
In fact I have been unable to think of any way to implement
this proposal in a fully shallow-bound system.
The problem is that the proposal requires that SPECIAL global references
and LEXICAL global references share the same value when there has been
no SPECIAL binding, but do not share when there has been a SPECIAL binding.
In a fully shallow-bound system (i.e. no environment search in SPECIAL
references and none in LEXICAL global references), this means that the
first SPECIAL binding has to do something unusual to separate the SPECIAL
value from the LEXICAL value, and the last SPECIAL unbinding has to undo
that.
Having turned my brain back on, I have now thought of an efficient way
to do this on Lisp machines, using invisible pointers, and another
efficient way to do it on stock hardware, using one extra instruction
on every global reference of one or the other sort, plus a few extra
instructions in SPECIAL binding and unbinding. Given that, I no longer
object to the proposal as unimplementable. However, I still think you
need to be more forthcoming about the cost to the implementor: it doesn't
just require a few compiler changes, it requires some reimplementation
of the representation of global variables, with concomitant changes to
the compiler, the loader, the interpreter, and probably the debugger.
Every symbol now potentially has two values accessible from the
interpreter (the current SPECIAL and the global LEXICAL) and you need
the corresponding new data structure to keep track of that.
A more cogent objection is that the proposal is incomplete. Common Lisp
includes a bunch of mechanisms related to global SPECIAL variables
(DEFVAR, SYMBOL-VALUE, MAKUNBOUND, etc.) and some or all of this needs
to be replicated for LEXICAL variables. I suspect not all of it needs
to be replicated, but you've got to discuss and decide.
I still think it would be good to do something resembling this.
∂28-Sep-88 0908 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 7)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:05:13 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04769; 28 Sep 88 16:11 BST
Date: Wed, 28 Sep 88 16:51:09 BST
Message-Id: <28871.8809281551@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: PROCLAIM-LEXICAL (Version 7)
To: Jon L White <@NSS.Cs.Ucl.AC.UK,@edu.stanford.edu:jonl@lucid.com>,
Moon@scrc-stony-brook.arpa
In-Reply-To: Jon L White's message of Tue, 27 Sep 88 23:56:21 PDT
Cc: KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu, JAR@ai.ai.mit.edu
> his might be something we shouldn't even think about standardizing
> until some implementor/vendor takes the plunge in a trial balloon,
> Yes, I remember, I was mildly in favor of the original proposal; but that
> was a year and a half ago, and I expected a GLOBAL declaration to mean that
> it would be illegal to special-bind that name (hence you could depend on
> that name *not* being in the D environment). Had somebody implemented
> something like it for their Lisp back then, we might have had results to
> talk about now.
I think the semantic implications of adding a declaration that prevents
dynamic binding are sufficiently straightforward that we should not
rule it out just because no one implemented it a year ago.
The strangeness in the current proposal is because the dynamic and
lexical environments meet in a separate global environment. So
a shallow bound implementation can't just change the global cell
when it pushes a new binding. The shallow binding cell has to
be a separate cell, making symbols (effectively) larger. KMP
and JAR suggested the use of a single cell combined with search
for the global value if both it and the dynamic are needed.
This is a new machanism, so we might want to think twice about
it.
An alternative is to say that a given global variable can be either
lexical or special but not (as they can be in the current proposal)
both. That's not all that strange, because it's what we get with
LET. It lets us use a single cell and simply rules out the case
when both are needed.
I believe this alternative (which is more or less what was proposed
before minus all the stuff about CONSTANT proclamations, etc.) solves
the main problems (an easily referenced global for deep bound
implementations and a way to establish a global variable without
proclaiming it special and without some implementations thinking
it's a spelling error or an omitted proclamation) and is fairly
noncontroversial.
We can fight about whether the proclamation for this should be called
GLOBAL or LEXICAL. I think it is better to think of the new kind of
global variable as a kind of lexical variable rather than as a
special1 variable that can't be bound, but that may be a matter of
taste.
We might also fight, I suppose, about whether there should be a
corresponding declaration (to override special proclamations).
[It occurs to me that people might think of two different
declarations.
1. (set-global x 10)
(let ((x 20))
(locally (declare (lexical x)) x)) => 20
2. (set-global x 10)
(let ((x 20))
(locally (declare (global x)) x)) => 10
The one I have in mind is the 1st.]
In any case, I think there is a fallback better than "do nothing".
∂28-Sep-88 0914 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:14:11 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467007; Wed 28-Sep-88 12:12:34 EDT
Date: Wed, 28 Sep 88 12:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: The message of 27 Sep 88 22:23 EDT from Scott.Fahlman@B.GP.CS.CMU.EDU
Message-ID: <880928121218.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 22:23:54 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Date: Tue, 27 Sep 88 13:04:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
I don't know what "variable definitions" means.
Does this mean that I, as a user, am not allowed to use symbols such as
LIST, MEMBER, or SYMBOL as a lexical variable in my own protable code? If
so, I am very strongly opposed to this. The conversion cost would be very
high, and I don't see any safety issue that would force us to restrict the
user in this way. If that is not the intended meaning, perhaps some
clearer wording is needed.
I'd go along with the other cases.
I wasn't really thinking about this issue, but I'd be happy if you
couldn't have global definitions of LIST, MEMBER, etc. or SPECIAL
bindings of them. But it's ok with me if you have lexical bindings of them.
Would that satisfy you. Does that seem to inconsistent to anyone?
∂28-Sep-88 0914 CL-Cleanup-mailer Re: Issue: PROCLAIM-LEXICAL (Version 7)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:05:13 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04769; 28 Sep 88 16:11 BST
Date: Wed, 28 Sep 88 16:51:09 BST
Message-Id: <28871.8809281551@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: PROCLAIM-LEXICAL (Version 7)
To: Jon L White <@NSS.Cs.Ucl.AC.UK,@edu.stanford.edu:jonl@lucid.com>,
Moon@scrc-stony-brook.arpa
In-Reply-To: Jon L White's message of Tue, 27 Sep 88 23:56:21 PDT
Cc: KMP@scrc-stony-brook.arpa, CL-Cleanup@sail.stanford.edu, JAR@ai.ai.mit.edu
> his might be something we shouldn't even think about standardizing
> until some implementor/vendor takes the plunge in a trial balloon,
> Yes, I remember, I was mildly in favor of the original proposal; but that
> was a year and a half ago, and I expected a GLOBAL declaration to mean that
> it would be illegal to special-bind that name (hence you could depend on
> that name *not* being in the D environment). Had somebody implemented
> something like it for their Lisp back then, we might have had results to
> talk about now.
I think the semantic implications of adding a declaration that prevents
dynamic binding are sufficiently straightforward that we should not
rule it out just because no one implemented it a year ago.
The strangeness in the current proposal is because the dynamic and
lexical environments meet in a separate global environment. So
a shallow bound implementation can't just change the global cell
when it pushes a new binding. The shallow binding cell has to
be a separate cell, making symbols (effectively) larger. KMP
and JAR suggested the use of a single cell combined with search
for the global value if both it and the dynamic are needed.
This is a new machanism, so we might want to think twice about
it.
An alternative is to say that a given global variable can be either
lexical or special but not (as they can be in the current proposal)
both. That's not all that strange, because it's what we get with
LET. It lets us use a single cell and simply rules out the case
when both are needed.
I believe this alternative (which is more or less what was proposed
before minus all the stuff about CONSTANT proclamations, etc.) solves
the main problems (an easily referenced global for deep bound
implementations and a way to establish a global variable without
proclaiming it special and without some implementations thinking
it's a spelling error or an omitted proclamation) and is fairly
noncontroversial.
We can fight about whether the proclamation for this should be called
GLOBAL or LEXICAL. I think it is better to think of the new kind of
global variable as a kind of lexical variable rather than as a
special1 variable that can't be bound, but that may be a matter of
taste.
We might also fight, I suppose, about whether there should be a
corresponding declaration (to override special proclamations).
[It occurs to me that people might think of two different
declarations.
1. (set-global x 10)
(let ((x 20))
(locally (declare (lexical x)) x)) => 20
2. (set-global x 10)
(let ((x 20))
(locally (declare (global x)) x)) => 10
The one I have in mind is the 1st.]
In any case, I think there is a fallback better than "do nothing".
∂28-Sep-88 0956 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (?)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 09:56:03 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467027; Wed 28-Sep-88 12:54:21 EDT
Date: Wed, 28 Sep 88 12:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (?)
To: jonl@Lucid.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809280615.AA06493@bhopal>
Message-ID: <880928125405.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 23:15:16 PDT
From: Jon L White <jonl@lucid.com>
re: How would you feel about something like the following. It's
broader, but still tries to be specific...
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
... I very much agree that vendors (and VAR's
like Intellicorp!!!) should not have any definitions "hanging off"
LISP symbols other than the mandated ones. However, this may spell
a bit of work for implementations like VAXLISP that use the property
list for compiler internals.
I didn't say anything about property lists. Property lists are safe as long
both the symbol and the indicator aren't global. Either of
(GET 'LISP:xxx 'PRIVATE:xxx)
and
(GET 'PRIVATE:xxx 'LISP:xxx)
is safe.
In fact, at one point in time, some of Lucid's window tool kit
implementation "leaked over" into the Lisp package; the symbol
POSITION had some random defstruct about it; and when a user
tried his own defstruct, he was overly surprised to see that
the system depended on that one [the windows package simply
forgot to shadow POSITION].
That's why I mentioned "types" above. I don't think you should have a
pre-defined type by this name, but not everyone puts types on the plist.
Jim Boyce here at Lucid has taken an interest in this matter; I'd
like to get him to write out a full critique, and possibly a new
proposal. In particular, he points out that we should also constrain
implementors from depending on the *lack* of any additional
definitions other than the CLtL ones. Can you imagine a vendor
selling a Lisp that _dies_ as soon as you do (defvar list 3)?
Right.
∂28-Sep-88 1049 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 10:47:30 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 SEP 88 09:23:05 PDT
Date: Wed, 28 Sep 88 09:21 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 3)
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809280541.AA06405@bhopal>
Message-ID: <19880928162127.8.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Tue, 27 Sep 88 22:41:16 PDT
From: Jon L White <jonl@lucid.com>
Add a DEFPACKAGE macro to the language. It encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
I think that at least IN-PACKAGE should not accept these options, and
should be used for selection only. The reason is the same as the one
for adding DEFPACKAGE. If you do this to IN-PACKAGE, people will end
up making the same mistake of using in-package with different arguments
in different files of their program.
Also, wherever it currently takes a symbol or a symbol-name (string), it
should just take a string. There are two reasons for this. The first
is simplicity, the current description of what happens with symbols is
confusing. More importantly is current practice. In systems which use
a "structure" editor, forms which take symbols as their argument, and
then change the print-name of those symbols, cause all sorts of
problems. So, at least the import options will cause problems for this
system.
-------
∂28-Sep-88 1102 CL-Cleanup-mailer Issue: TYPE-OF-UNDERCONSTRAINED
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 11:01:30 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467081; Wed 28-Sep-88 14:00:01 EDT
Date: Wed, 28 Sep 88 13:59 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TYPE-OF-UNDERCONSTRAINED
To: masinter.pa@Xerox.COM
cc: cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <880921-024739-5696@Xerox>
Message-ID: <19880928175947.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 21 Sep 88 02:47 PDT
From: masinter.pa@Xerox.COM
This is in response to mail under COERCE-FROM-TYPE and TYPE-OF. I would prefer
to constrain TYPE-OF to be at least as specific as (CLASS-NAME (CLASS-OF x)).
That seems like a reasonable idea.
I'm less sure what to do about instances of unnamed classes; the Medley way
would be to return the class itself for an otherwise nameless class.
TYPE-OF could return NIL in that case, which is a subtype of everything (ha ha).
Since CLOS says class objects are acceptable wherever type specifiers are,
I think the Medley way is okay.
This would disallow what is otherwise "legal" now: namely to have TYPE-OF return
T for everything but structure instances.
I think it probably is reasonable also to constrain TYPE-OF to be something that
SUBTYPEP can deal with. (cf SUBTYPEP-TOO-VAGUE).
I'm less sure of this, since I can't figure out if there are any ramifications.
It's not worth putting a lot of effort into TYPE-OF, since if you want something
well-defined you definitely use CLASS-OF rather than TYPE-OF.
∂28-Sep-88 1156 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 2)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 11:56:37 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 28 Sep 88 14:53:42 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: PACKAGE-CLUTTER (Version 2)
In-reply-to: Your message of Wed, 28 Sep 88 12:12:00 -0400.
<880928121218.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 28 Sep 88 14:53:08 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
I wasn't really thinking about this issue, but I'd be happy if you
couldn't have global definitions of LIST, MEMBER, etc. or SPECIAL
bindings of them. But it's ok with me if you have lexical bindings of them.
Would that satisfy you. Does that seem to inconsistent to anyone?
It would satisfy me to say that can't be proclaimed special (they're
spelled wrong for that anyway -- not surrounded by stars), and that it is
an error to special-bind any of these. I'm wary of the cost is we say
"signals an error".
As for global bindings, it depends on what that "global" ends up meaning.
I can't think about that yet, since I have not totally internalized the
implications of the various proposals flying around.
-- Scott
∂28-Sep-88 1307 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:07:18 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00937g; Wed, 28 Sep 88 12:04:46 PST
Received: by bhopal id AA09299g; Wed, 28 Sep 88 13:04:19 PDT
Date: Wed, 28 Sep 88 13:04:19 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809282004.AA09299@bhopal>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Wed, 28 Sep 88 14:53:08 EDT <8809281858.AA00875@lucid.com>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
Say, you guys have been discussing the LISP-SYMBOL-REDEFINITION issue
under the banner of "Issue: PACKAGE-CLUTTER". Wanna switch?
-- JonL --
∂28-Sep-88 1311 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:11:47 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 323211; Wed 28-Sep-88 16:09:17 EDT
Date: Wed, 28 Sep 88 16:09 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: jonl@lucid.com
cc: Scott.Fahlman@B.GP.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809282004.AA09299@bhopal>
Message-ID: <880928160917.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 28 Sep 88 13:04:19 PDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Wed, 28 Sep 88 14:53:08 EDT <8809281858.AA00875@lucid.com>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
Say, you guys have been discussing the LISP-SYMBOL-REDEFINITION issue
under the banner of "Issue: PACKAGE-CLUTTER". Wanna switch?
-- JonL --
I guess I accidentally broadened the issue when I changed some sentence
that said "the system can't provide..." to say "no one can..." or some
such thing. It's just as dangerous for the user to do it as the system,
so the issues are related. Would it make sense to merge the issues as
a single new issue LISP-SYMBOL-DEFINITION? I'd prefer to do that rather
than ask people to talk about only half the subject at a time. If after
more discussion we needed to break it back out into two topics, we could
still do so...
∂28-Sep-88 1322 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:22:52 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00967g; Wed, 28 Sep 88 12:20:22 PST
Received: by bhopal id AA09354g; Wed, 28 Sep 88 13:19:55 PDT
Date: Wed, 28 Sep 88 13:19:55 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809282019.AA09354@bhopal>
To: Gregor.pa@Xerox.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Wed, 28 Sep 88 09:21 PDT <19880928162127.8.GREGOR@PORTNOY.parc.xerox.com>
Subject: Issue: DEFPACKAGE (version 3)
re: I think that at least IN-PACKAGE should not accept these options, and
should be used for selection only. The reason is the same as the one
for adding DEFPACKAGE. If you do this to IN-PACKAGE, people will end
up making the same mistake of using in-package with different arguments
in different files of their program.
The relevant section of the proposal (version 3) reads:
Also expand MAKE-PACKAGE (and IN-PACKAGE, unless the cleanup Issue
IN-PACKAGE-FUNCTIONALITY is adopted) to take all the same keyword
arguments as DEFPACKAGE, for consistency.
As moon rightly points out, we have to address the pull-back of
IN-PACKAGE separately, since it is a serious incompatible change.
[Note that I'm agreeing with you -- I just want to move the discussion
about it into the pre-existing Cleanup issue.]
re: Also, wherever it currently takes a symbol or a symbol-name (string), it
should just take a string. . . .
I'd certainly be happy with that, but my impression is that moon and kmp
feel it is important to be able to use symbols just for their print-name;
the issue being that case-conversion happens automatically for symbols,
but doesn't for strings. Given the option to use strings everywhere, and
given implementation techniques that permit the compiler to evade package
issues (in the compiled output for a DEFPACKAGE), this admission to "lazy
typing" seems harmless. Note also that many users have discovered the
wonderous insensitivity to package problems that the notations :FOO and
#:FOO have.
re: . . . In systems which use
a "structure" editor, forms which take symbols as their argument,
and then change the print-name of those symbols, cause all sorts of
problems. So, at least the import options will cause problems for
this system.
-------
There is no common-lisp capability to "change the print-name" of symbols.
This DEFPACKAGE proposal doesn't suggest that, so if you think it implied
it somehow, maybe you could point out the confusing phrases.
-- JonL --
∂28-Sep-88 1355 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 13:55:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467279; Wed 28-Sep-88 16:52:55 EDT
Date: Wed, 28 Sep 88 16:52 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 3)
To: jonl@lucid.com
cc: Gregor.pa@Xerox.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@Sail.stanford.edu
In-Reply-To: <8809282019.AA09354@bhopal>
Message-ID: <880928165233.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Wed, 28 Sep 88 13:19:55 PDT
From: Jon L White <jonl@lucid.com>
...
re: Also, wherever it currently takes a symbol or a symbol-name (string), it
should just take a string. . . .
I'd certainly be happy with that, but my impression is that moon and kmp
feel it is important to be able to use symbols just for their print-name;
the issue being that case-conversion happens automatically for symbols,
but doesn't for strings.
Just Moon thinks this. KMP is strongly in favor of accepting strings only
because he thinks the issue of stray symbols being accidentally interned
in the wrong package is considerably more important than the issue of making
someone type "FOO" instead of "foo".
(On the other hand, KMP programs about half the time in uppercase and
half the time in lower case and has no particular phobia of seeing uppercase
characters in a mostly lowercase program, so maybe he undervalues the
importance to some people of never seeing an uppercase character anywhere
in their code. :-)
... Note also that many users have discovered the wonderous insensitivity
to package problems that the notations :FOO and #:FOO have. ...
(Only half-serious, I think) Maybe we should permit only unpackaged symbols
or symbols in the keyword package...
∂28-Sep-88 1453 CL-Cleanup-mailer Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:53:02 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01076g; Wed, 28 Sep 88 13:50:55 PST
Received: by bhopal id AA09835g; Wed, 28 Sep 88 14:50:29 PDT
Date: Wed, 28 Sep 88 14:50:29 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809282150.AA09835@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
In Kent's note of Tue, 27 Sep 88 12:25 EDT, he points out the action
of MAKE-PACKAGE, for an existing package, is to "break" (in most
implementations.) It occurs to me that the DEFPACKAGE proposal
is silent (hence, subject to varying interpretations) about how to
handle the case of defining a package on a name that already exists.
I see three possibilities:
(1) "break", just like MAKE-PACKGE
(2) Simply do the new definition (as DEFUN and DEFCLASS do), possibly
issuing a warning message based upon vendor-specific facilities.
(3) Quietly do the new definition, providing that it is essentially
compatible with the old one; signal an error if not compatible.
I think I'd prefer (3), since it allows you to re-load a file that
is under development, without getting spurious breaks or warning
messages; yet it provides some assurance that you aren't about to
break your whold world.
Comments?
-- JonL --
∂28-Sep-88 1500 CL-Cleanup-mailer back....
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 14:58:48 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 14:50:52 PDT
Date: 28 Sep 88 14:49 PDT
From: masinter.pa@Xerox.COM
Subject: back....
To: cl-cleanup@sail.stanford.edu
Message-ID: <880928-145052-1699@Xerox>
I forgot to send out a message that I'm actually back... I'm still swamped by
cleanup mail, and really would still like new revised, clean, agreeable
proposals from you asap.
Thanks,
Larry
∂28-Sep-88 1503 CL-Cleanup-mailer Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Sep 88 15:03:00 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 467326; Wed 28-Sep-88 18:01:26 EDT
Date: Wed, 28 Sep 88 18:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
To: jonl@lucid.com
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM,
KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8809282150.AA09835@bhopal>
Message-ID: <880928180109.6.KMP@GRYPHON.SCRC.Symbolics.COM>
I like option 3, too. But I note that all kinds of packages are
going to be defined as just :USE LISP and nothing else, so that's
not enough safeguard to be completely sure that clobberage is not
occurring. I think we (Symbolics) will want to provide
[implementation-dependent] support for complaining more forcefully
if the DEFPACKAGE is in a different file than the previous one
(to help us distinguish re-loading from clobbering back and forth),
so try to leave the wording vague enough to accomodate discretion
about exactly why the error might be signalled in the case of
redefinition.
∂28-Sep-88 1519 CL-Cleanup-mailer Re: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 15:19:36 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 15:06:38 PDT
Date: 28 Sep 88 15:06 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issues: IN-PACKAGE-FUNCTIONALITY and DEFPACKAGE
In-reply-to: Jon L White <jonl@lucid.com>'s message of Wed, 28 Sep 88 14:50:29
PDT
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880928-150638-1741@Xerox>
I like it, but it is necessary to define what "essentially compatible" means.
Please.
∂28-Sep-88 1614 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:14:45 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01194g; Wed, 28 Sep 88 15:12:19 PST
Received: by bhopal id AA10177g; Wed, 28 Sep 88 16:11:51 PDT
Date: Wed, 28 Sep 88 16:11:51 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809282311.AA10177@bhopal>
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
Cc: Jon L White <@NSS.Cs.Ucl.AC.UK,@edu.stanford.edu:jonl@lucid.com>,
Moon@scrc-stony-brook.arpa, KMP@scrc-stony-brook.arpa,
CL-Cleanup@sail.stanford.edu, JAR@ai.ai.mit.edu
In-Reply-To: Jeff Dalton's message of Wed, 28 Sep 88 16:51:09 BST <28871.8809281551@subnode.aiai.ed.ac.uk>
Subject: Issue: PROCLAIM-LEXICAL (Version 7)
re: I think the semantic implications of adding a declaration that prevents
dynamic binding are sufficiently straightforward that we should not
rule it out just because no one implemented it a year ago.
Of course, your right. I was reacting to the added complication
more recently added to permit "mixing" the D and G situations.
re: The strangeness in the current proposal is because the dynamic and
lexical environments meet in a separate global environment. So
a shallow bound implementation can't just change the global cell
when it pushes a new binding. The shallow binding cell has to
be a separate cell, making symbols (effectively) larger. KMP
and JAR suggested the use of a single cell combined with search
for the global value if both it and the dynamic are needed.
This is a new machanism, so we might want to think twice about
it.
I think moon was right that the problem is really parallel to the
implementation of deep binding. In fact, PDP10 MacLisp is "shallow
bound", but implemented the restoration stack in such a way that
it could find the toplevel value, or any intermediate value, simply
by "walking" back up that stack -- very similar to a deep-bound
search [and such "walking" was in fact used when applying downward
funargs]. There are numerous "cacheing" techniques to accellerate
deep-bound searches, so I'm not making an inherent performance criticism;
rather, I fear that this is a new arena for all except perhaps ENVOS
[and Lucid's QLISP] and that simply taking on this coding task and
all its performance implications is a venture much bigger than I'd
like to see labelled as "cleanup".
re: . . .
I believe this alternative (which is more or less what was proposed
before minus all the stuff about CONSTANT proclamations, etc.) solves
the main problems (an easily referenced global for deep bound
implementations and a way to establish a global variable without
proclaiming it special and without some implementations thinking
it's a spelling error or an omitted proclamation) and is fairly
noncontroversial.
This is what I thought I liked about the proposal long ago.
re: In any case, I think there is a fallback better than "do nothing".
Hope so!
-- JonL --
∂28-Sep-88 1619 CL-Cleanup-mailer Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:19:26 PDT
Posted-Date: Wed, 28 Sep 88 15:17:11 PST
Message-Id: <8809282317.AA00889@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.54/5.51)
id AA00889; Wed, 28 Sep 88 16:17:45 PDT
To: CL-Cleanup@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Re: Issue: DOTTED-MACRO-FORMS (Version 1)
Cc: KMP@stony-brook.scrc.symbolics.com, goldman@vaxa.isi.edu,
masinter.pa@xerox.com
Date: Wed, 28 Sep 88 15:17:11 PST
Sender: goldman@vaxa.isi.edu
First, thank you guys for getting this issue considered and keeping the
ball rolling. Since I guess I am the one who suggested that it should
be dealt with, I think I should at least state why I thought dotted
macro forms should not be outlawed out of hand.
1) Like Larry, I don't like macro extensions that encourage source code
programs to have a "dotted list" representation. But I don't think I
understand why I don't like them well enough to feel comfortable
making them officially "discouraged". It may be that it is only the
PRINTED REPRESENTATION I don't like -- that pretty printers I have used
don't seem to format them the way I would choose to, and that the "."
doesn't stand out sufficiently and I miss it when looking at the
printed representation.
2) The situation that brought this issue to my attention had to do with
programs generated not by people, but by an "automatic programmer"
(or a hairy set of macros, if you prefer a more earthy characterization.)
The dotted macro form was not intended to ever be written or seen by a
human programmer; just processed by the compiler if it happened to be
produced by these other macros. Here is a synopsis. See if you think
it meets Larry's characterization as "occasionally ... just the right thing.":
Our automatic programmer produces and compiles high-level queries to a
database. A query is representated by a well-formed-formula (WFF). A
primitive WFF consists of a list -- (<relation-name> arg1 ... argn) --
e.g. (GRADE student course grade).
These primitive WFFs can be negated, combined with AND and OR, and
embedded in quantifiers. So a compound WFF might be:
"did s1 outperform s2 in any course?"
(exists (course g1 g2) (AND (GRADE s1 course g1)
(GRADE s2 course g2)
(GRADE> g1 g2)))
The syntax we chose for posing a query to the database from a lisp program
is (?? . WFF). Notice that the syntax for WFFs guarantees that they are
all pure lists, so (?? . WFF) will never be a dotted macro form.
[WFFs are also used in many other parts of our embedded language.]
We also have a "simplifier" for wffs. It is logically possible for
a wff to be simplifiable to the point that its truth is independent of the
contents of the database -- e.g.,
(OR (GRADE s c g) (NOT (GRADE s c g)))
is tautologically true, while other WFFs might be provably true or false
based on reasoning about constraints known about the data. We needed
to represent two logical constants, and we chose to represent them by
the symbols TRUE and FALSE. It turns out that these logical constants made
sense wherever WFFs made sense; in particular,
(?? . TRUE)
is a perfectly fine query; it is one that no programmer would ever
write DIRECTLY, but might be produced by some automatic programmer tool.
We defined the macroexpander for ?? so that (?? . TRUE) macroexpands to T,
and (?? . FALSE) to NIL. But now we had introduced the possibiltiy of
dotted macro forms, and discovered, when testing, that various implementations
were inconsistent (sometimes even self-inconsistent) in their treatment of
these forms.
3) I don't remember whether I ever expressed my opinion on how this issue
would be best resolved. My apologies if the following is a repetition of
an earlier submission.
I do think that support for portable dotted macros should be provided.
I don't think it would be so bad (in fact, I think it would be GOOD) if
the "normal" case (the macro cannot be correctly used with a dotted
argument list) caused dotted lists to be caught and an error signalled by
Lisp's macroexpander, rather than expecting the programmer's expansion
code detect it.
Pragmatically, I believe that most macros written with &rest are NOT
prepared to deal with "dotted" lists in the &rest variable (or atomic,
non-nil, values of the &rest variable). If invoked with the &rest variable
so bound, these macroexpanders will almost invariably either
a) produce an expansion which will propogate the dotted argument list
to another macro or function (postponing detection of the error), or
b) cause an expansion-time error by doing car/cdr on a non list,
which the programmer will trace back to being caused by the dotted argument
list, or
c) (by poor programming) terminate cdring down the &rest list with a consp
test nstead of an endp check, masking the error entirely.
If LISP were REQUIRED to signal an error when an &rest macro parameter
"matched" a dotted list, or non-nil atom, then macro writers would not
have to check the condition themselves to get good error messages.
However, a declaration could be provided:
(defmacro foo (x &optional y &rest z)
(declare (allow-dotted z))
...)
in which case an error would NOT be signalled on (foo x1 y1 z1 . z2)
I have not seen many actual uses of &WHOLE. Certainly the same
declaration could be used to control whether or not and &WHOLE parameter
could bind to a dotted list. Is there anything about the use of &WHOLE
that would lead you to expect its "normal" usage would make a default of
"dotted lists are an error" less reasonable than for &rest ?
For instance, if it is mostly used in the idiom:
(defmacro MW (&whole form)
<record something about form>
`(MW-INTERNAL ,. (rest form)))
where MW-INTERNAL is another macro, then it would be
better to let MW-INTERNAL be responsible for controlling whether
dotted arglists were acceptable, and never complain about binding them
to &WHOLE parameters.
----------------------------------------------------------------
Neil
∂28-Sep-88 1645 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from EDDIE.MIT.EDU by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:45:37 PDT
Received: by EDDIE.MIT.EDU with UUCP with smail2.5 with sendmail-5.45/4.7 id <AA09075@EDDIE.MIT.EDU>; Wed, 28 Sep 88 19:43:21 EDT
Received: by spt.entity.com (smail2.5); 28 Sep 88 18:08:31 EDT (Wed)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Scott.Fahlman@B.GP.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 28 Sep 88 12:12 EDT <880928121218.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
Message-Id: <8809281808.AA29619@spt.entity.com>
Date: 28 Sep 88 18:08:31 EDT (Wed)
From: gz@spt.entity.com (Gail Zacharias)
Date: Wed, 28 Sep 88 12:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I wasn't really thinking about this issue, but I'd be happy if you
couldn't have global definitions of LIST, MEMBER, etc. or SPECIAL
bindings of them. But it's ok with me if you have lexical bindings of them.
Would that satisfy you. Does that seem to inconsistent to anyone?
Yes. I sometimes find it useful to put temporary special declarations on
normally-lexical variables as a q&d debugging technique. I don't see why I
shouldn't be allowed to do this for a variable named LIST. I also don't see
why I shouldn't be allowed to have a macro named MOST-POSITIVE-FIXNUM. In
fact I don't really understand the motivation for putting ANY restrictions on
USERS wrt this issue. It seems to be mainly a matter of style or good
programming practice but then so is putting *'s around specials, and the
standard isn't going to require that. If a programmer doesn't choose to be
concerned about co-existing with other programs in the same lisp, that's his
business. He might even know what he's doing. Implementations might want to
issue warnings in such cases, but that's not the same as making such programs
arbitrarily illegal.
∂28-Sep-88 1656 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 16:56:14 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 16:48:00 PDT
Date: Wed, 28 Sep 88 16:47 PDT
From: Gregor.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 3)
To: Jon L White <jonl@lucid.com>
cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: <8809282019.AA09354@bhopal>
Message-ID: <19880928234749.5.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
Date: Wed, 28 Sep 88 13:19:55 PDT
From: Jon L White <jonl@lucid.com>
There is no common-lisp capability to "change the print-name" of symbols.
This DEFPACKAGE proposal doesn't suggest that, so if you think it implied
it somehow, maybe you could point out the confusing phrases.
I should have said "the way a symbol is printed". In a programming
environment in which the users program passes through READ and PRINT
this is an issue. Given that package is bound to some package FOO which
only uses LISP, this form:
(import 'pcl::class-direct-slots)
Once I read this form, it will print out as:
(IMPORT 'CLASS-DIRECT-SLOTS)
So that when I load it again in a fresh world, I won't get the result
I got the first time.
-------
∂28-Sep-88 1752 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:52:21 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 28 SEP 88 17:41:58 PDT
Date: 28 Sep 88 17:41 PDT
From: vanMelle.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 2)
To: cl-cleanup@Sail.stanford.edu
cc: vanMelle.pa@Xerox.COM
Message-ID: <880928-174158-2043@Xerox>
I strongly agree with JonL on point one, that it is important that the spec
permit strings in all the places that currently say "symbol" (except, of course,
:import and :shadowing-import). I don't want to be forced to use a form that
has a side effect of interning random symbols that I'm then going to discard.
As a simple example, the following sequence:
(in-package 'user)
(defpackage foo (:export bar baz))
(use-package 'foo)
will complain that foo:bar conflicts with user::bar. Environments with
residential structure editors probably feel even more strongly of the need for
strings. I take it there was no serious disagreement on this.
JonL's second point, that :import and :shadowing-import should be flushed, is
less clear. I agree with Moon that allowing a user to type foo::bar in a
defpackage is no worse than allowing it in some random program. I also agree
with JonL that :[shadowing-]import is of relatively little utility given the
existence of :[shadowing-]import-from. I see it mainly as a shorthand (and a
perfectly "safe" one in the case of external symbols), though not one that saves
more than typing a couple of parentheses. Here are a couple other arguments for
getting rid of :[shadowing-]import on aesthetic grounds:
(1) It's the only option that really does require symbols. If you omit it, you
can explain the various options solely in terms of pnames, without constantly
saying "if symbol, only its name is used". JonL alludes to this.
(2) It's unusable altogether in residential environments unless the environment
goes to special effort to be careful. E.g., if I read in the form
(defpackage foo (:import window:bar))
and later print it out in the foo package, it comes out as
(defpackage foo (:import bar))
which, of course, is not what I had in mind.
At any rate, the spec really should spell out what :import-from does if the
specified symbol is not accessible in the package. I.e., does it behave like
(:import package::name), thus creating the symbol anyway, or like (or
(find-symbol name package) (error ...)).
By the way, there are a couple things missing from the proposal that really need
to be stated somewhere, though I doubt any of them are difficult to answer:
(1) What, exactly, does defpackage do? Yes, it creates the package according to
the specified options. Does it do also do an in-package? Does it return the
package as value?
(2) What happens when the package already exists? Nothing? Overrides previous
options? "Union" of both? I think the union method is best, but it may also
require more explaining.
Bill
∂28-Sep-88 1755 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 17:55:05 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01347g; Wed, 28 Sep 88 16:52:46 PST
Received: by bhopal id AA10573g; Wed, 28 Sep 88 17:52:20 PDT
Date: Wed, 28 Sep 88 17:52:20 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809290052.AA10573@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Scott.Fahlman@B.GP.CS.CMU.EDU, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Wed, 28 Sep 88 16:09 EDT <880928160917.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
re: ... Would it make sense to merge the issues as
a single new issue LISP-SYMBOL-DEFINITION? I'd prefer to do that rather
than ask people to talk about only half the subject at a time. ...
I thought the PACKAGE-CLUTTER issue successfully attacked the problem
of what symbols should be present in the LISP package. The constraint
about vendors not putting additional definitions on LISP package
symbols seems ok in this context, but widening it out to a proscription
agains the user "using" these names seem better suited to the context
of LISP-SYMBOL-REDEFINITION.
The former issue seems to be (finally!) non-controversial; but the latter
is sure to have ongoing dissension.
-- JonL --
∂28-Sep-88 1846 CL-Cleanup-mailer Issue: DEFPACKAGE (version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 28 Sep 88 18:46:33 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01414g; Wed, 28 Sep 88 17:43:59 PST
Received: by bhopal id AA10743g; Wed, 28 Sep 88 18:43:33 PDT
Date: Wed, 28 Sep 88 18:43:33 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809290143.AA10743@bhopal>
To: Gregor.pa@Xerox.COM
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@Sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM's message of Wed, 28 Sep 88 16:47 PDT <19880928234749.5.GREGOR@PORTNOY.parc.xerox.com>
Subject: Issue: DEFPACKAGE (version 3)
re: I should have said "the way a symbol is printed". In a programming
environment in which the users program passes through READ and PRINT
this is an issue. Given that package is bound to some package FOO which
only uses LISP, this form:
(import 'pcl::class-direct-slots)
Once I read this form, it will print out as:
(IMPORT 'CLASS-DIRECT-SLOTS)
So that when I load it again in a fresh world, I won't get the result
I got the first time.
This is precisely one of the situations that I've been referring to
when I argue for the removal of the :IMPORT option. Note however,
that the revised proposal does *not* have this misfeature even if
you use _symbols_ in the :IMPORT-FROM option. That's the whole point
of it. [Yes, your structure editor might package-qualify one such
symbol differently, if PRINTed at the "wrong" times, but that will be
completely irrelevant.]
You did mention before that you found the documentation about the
symbols-vs-strings as arguments somewhat unclear, so maybe this
point didn't get through. Wanna suggest some re-wordings?
-- JonL --
P.S. By the bye, are you aware of the existence of the Decency in Packaging
League, which will slap you with a citation for writing code like:
(import 'pcl::class-direct-slots)
rather than:
(import (intern "CLASS-DIRECT-SLOTS" "PCL"))
∂28-Sep-88 1939 CL-Cleanup-mailer on Splitting and Merging issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 28 Sep 88 19:39:04 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 19:31:36 PDT
Date: 28 Sep 88 19:31 PDT
From: masinter.pa@Xerox.COM
Subject: on Splitting and Merging issues
To: CL-Cleanup@Sail.stanford.edu
Message-ID: <880928-193136-2162@Xerox>
Merging issues is time-consuming and risky. On these tightly intertwined issues
(e.g., DEFPACKAGE and IN-PACKAGE-FUNCTIONALITY, PACKAGE-CLUTTER and
LISP-SYMBOL-REDEFINITION), I thought I might present them both to X3J13 before
any discussion of either of them. Its almost as good as merging them, but does
allow us to agree on one and continue to discuss the other without the
additional confusion.
∂29-Sep-88 0705 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION)
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 07:05:45 PDT
Received: by decwrl.dec.com (5.54.5/4.7.34)
id AA06406; Thu, 29 Sep 88 07:49:36 PDT
Date: Thu, 29 Sep 88 07:49:36 PDT
Message-Id: <8809291449.AA06406@decwrl.dec.com>
From: vanroggen%aitg.DEC@decwrl.dec.com
To: cl-cleanup@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (formerly FUNCTION-DECLARATION)
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
The most important problem, though, is that using the same declaration for two
completely different purposes can lead to confusion among people writing or
reading such code.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
VAX LISP treats FUNCTION declarations only as abbreviations for FTYPE
declarations.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods (MTYPE?).
Since all cases can be disambiguated after all (the original proposal
didn't realize that one couldn't declare the type of the constant NIL to
be a FUNCTION), compatibility considerations might deem this proposal to
be unnecessary. However, van Roggen believes that making declarations
simpler and less confusing is more important than compatibility in this case.
The proposal was renamed from FUNCTION-DECLARATION after Masinter pointed out
that this issue had already been considered and named.
∂29-Sep-88 0727 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Sep 88 07:27:46 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 28 SEP 88 23:42:19 PDT
Date: 28 Sep 88 23:42 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: DEFPACKAGE (version 3)
In-reply-to: vanMelle.pa's message of 28 Sep 88 17:41 PDT
To: cl-cleanup@Sail.stanford.edu
cc: vanmelle.pa@Xerox.COM
Message-ID: <880928-234219-233@Xerox>
I think we're very close on this one.
As for Bill's questions:
DEFPACKAGE should in fact do an in-package? In fact, isn't it simply written portably?
I like removing features.
∂29-Sep-88 1632 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 16:32:23 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00331g; Thu, 29 Sep 88 15:30:15 PST
Received: by bhopal id AA13827g; Thu, 29 Sep 88 16:29:48 PDT
Date: Thu, 29 Sep 88 16:29:48 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809292329.AA13827@bhopal>
To: vanMelle.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: vanMelle.pa@Xerox.COM's message of 28 Sep 88 17:41 PDT <880928-174158-2043@Xerox>
Subject: Issue: DEFPACKAGE (version 2)
re: I strongly agree with JonL on point one, that it is important that the spec
permit strings in all the places that currently say "symbol" (except ...
(version 2) actually says "symbol-name" rather than "symbol"; I think moon
agreed to this in a message last May.
re: . . . allowing a user to type foo::bar in a defpackage
is no worse than allowing it in some random program.
Well, damage is often in the eye of the beholder, but DEFPACKAGE is a bit
of a "lever" in that if you don't need colon qualifications in it, you can
generally say that you don't need it in your file at all. Let's grant for
the moment that single-colon qualifiers in files are bad; so bad that even
just *one* of them can be disastrous (as another part of your msg suggests).
Then with a proper use of DEFPACKAGE, you can almost always "import" etc the
needed symbols so that they are available unqualified; but if you can't even
name them in order to import them, you've completely lost "the battle of the
colons". Thus the whole issue swings on the optionality of symbols in the
options to DEFPACKAGE.
re: At any rate, the spec really should spell out what :import-from does if the
specified symbol is not accessible in the package. I.e., does it ...
Bill, are you sure you've been reading (version 2) and not (version 1)? This
point was also recently changed; the specification of :IMPORT-FROM says:
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified packages and import
them into the package being defined. . . . In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible for
one of the names in its corresponding "from" package. ...
re: (1) What, exactly, does defpackage do? ... Does it do also do an
in-package? Does it return the package as value?
Good point. It's probably arbitrary, but should be spelled out.
re: (2) What happens when the package already exists? I think the union
method is best, but it may also require more explaining.
My msg of Date: Wed, 28 Sep 88 14:50:29 PDT proposed three alternatives;
your suggestion of "union" is probably similar to alternative (3), which
KMP also favored. I see that we need some discusson on this point of what
it means to "resolve" an existing package with a candidate new definition.
Got any ideas?
-- JonL --
∂29-Sep-88 1733 CL-Cleanup-mailer Issue: DEFPACKAGE (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Sep 88 17:33:13 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00392g; Thu, 29 Sep 88 16:31:09 PST
Received: by bhopal id AA14046g; Thu, 29 Sep 88 17:30:42 PDT
Date: Thu, 29 Sep 88 17:30:42 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8809300030.AA14046@bhopal>
To: vanMelle.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: Jon L White's message of Thu, 29 Sep 88 16:29:48 PDT <8809292329.AA13827@bhopal>
Subject: Issue: DEFPACKAGE (version 2)
Foo, whereever my message said "(version 2)", I meant to say "(version 3)".
Version 3 is the one I sent out on Date: Tue, 27 Sep 88 22:41:16 PDT
correcting most of the problems you brought up in yesterday's note.
-- JonL --
∂30-Sep-88 1020 CL-Cleanup-mailer Re: Issue: DEFPACKAGE (version 3)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 30 Sep 88 10:16:46 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa05436; 30 Sep 88 17:16 BST
Date: Fri, 30 Sep 88 17:57:28 BST
Message-Id: <2809.8809301657@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: DEFPACKAGE (version 3)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>,
jonl <@sail.stanford.edu:jonl@lucid.com>
In-Reply-To: Kent M Pitman's message of Wed, 28 Sep 88 16:52 EDT
Cc: Gregor.pa@xerox.com, Moon@scrc-stony-brook.arpa,
CL-Cleanup@sail.stanford.edu
> Date: Wed, 28 Sep 88 13:19:55 PDT
> From: Jon L White <jonl@lucid.com>
>
> I'd certainly be happy with that, but my impression is that moon and kmp
> feel it is important to be able to use symbols just for their print-name;
> the issue being that case-conversion happens automatically for symbols,
> but doesn't for strings.
>
> Just Moon thinks this.
I think so too. I dislike being forced to use upper case;
I'd reather use :foo than "FOO".
Of course, if we were to change the internal case to lower (perhaps,
for backwards compatibility, using a canonical case trick like the
one suggested for pathnames), this problem would disappear for me,
though perhaps not for someone who was concerned about case conversion
per se (no matter what the internal case) rather than about upper
verses lower.
> (On the other hand, KMP programs about half the time in uppercase and
> half the time in lower case and has no particular phobia of seeing uppercase
> characters in a mostly lowercase program, so maybe he undervalues the
> importance to some people of never seeing an uppercase character anywhere
> in their code. :-)
Maybe the lower case on the machines you use isn't very readable, so
that upper case doesn't seem so bad. :-)
> ... Note also that many users have discovered the wonderous insensitivity
> to package problems that the notations :FOO and #:FOO have. ...
>
> (Only half-serious, I think) Maybe we should permit only unpackaged symbols
> or symbols in the keyword package...
It's worth considering.
∂30-Sep-88 1419 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Sep 88 14:19:06 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468565; Fri 30-Sep-88 17:17:47 EDT
Date: Fri, 30 Sep 88 17:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880930171700.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Issue: KILL-PACKAGE
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
There is no way to kill a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (KILL-PACKAGE:NEW-FUNCTION):
Introduce the function KILL-PACKAGE, described as follows:
KILL-PACKAGE package [Function]
Kills PACKAGE by removing it from all package system data structures.
PACKAGE may be a package or the name of a package.
If PACKAGE names a package which does not exist, or is a package
object which has been killed already, an error is signalled.
The name and nicknames of the designated package cease to be
recognized package names.
If the designated package is used by other packages, the effect of
UNUSE-PACKAGE is done to remove that dependency, causing its external
symbols to stop being accessible to those packages.
Any symbols in the designated package still exist after this function
is called. If their home package was not the package to be killed, the
home package will be unchanged. If their home package was that package,
the home package after this operation is unspecified; the effect of
printing such symbols is also unspecified.
The designated package persists after this function is called.
PACKAGEP is still true of it, but PACKAGE-NAME will return NIL.
The effect of any other package operation on PACKAGE is undefined.
KILL-PACKAGE returns T.
Test Case:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(KILL-PACKAGE *BAR-PACKAGE*)
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior.
When a package is killed the home package of all symbols in that package
are left undisturbed (i.e., local symbols pointing to the killed package).
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the KILL-PACKAGE
to take care of worrying about the effects of having killed the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Killing a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Pitman supports this addition.
∂30-Sep-88 1550 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 30 Sep 88 15:50:15 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468640; Fri 30-Sep-88 18:48:15 EDT
Date: Fri, 30 Sep 88 18:47 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROFLET (Version 1)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
References: <880920-175312-5239@Xerox>
Message-ID: <880930184754.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 20 Sep 88 17:53 PDT
From: masinter.pa@Xerox.COM
Is this a cleanup issue/proposal or just an interesting discussion?
I thought about it and decided I'd better write it up.
The more I think of it, the more I'm inclined to believe it would
be really useful (and perhaps quite hard to do without).
-kmp
-----
Issue: SYMBOL-MACROFLET
References: None
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The SYMBOL-MACROLET facility provides access to only one of the two
Common Lisp namespaces.
For example, in the expression (F G), it is possible to bind the
semantics of G using SYMBOL-MACROLET, but there is no analogous
facility for binding the semantics of F.
The ability to have symbol-macros in the functional namespace would
make the creation of a Flavors compatibility package for CLOS much
more feasible. In particular, the DEFUN-IN-FLAVOR feature of Flavors
is not easy to implement efficiently without it.
Proposal (SYMBOL-MACROFLET:NEW-MACRO):
Introduce a new macro, SYMBOL-MACROFLET, described as follows:
SYMBOL-MACROFLET ({(symbol expansion)}*) &BODY forms
The macro SYMBOL-MACROFLET provides a mechanism for the substitution
of functional expressions for function names with a lexical scope.
The SYMBOL argument specifies the symbol with which the form
specified by the EXPANSION argument is to be associated.
Each reference to SYMBOL as a function within the lexical scope of
SYMBOL-MACROFLET is replaced by EXPANSION (not the result of evaluating
EXPANSION).
The result is that obtained by executing the forms specified by the
body FORMS.
The lexical scope of SYMBOL-FMACROLET is the body FORMS; it does not
include EXPANSION.
The use of SYMBOL-MACROFLET can be shadowed by FLET or MACROLET. In
other words, SYMBOL-MACROFLET only substitutes for occurrences of SYMBOL
that would be in the scope of a lexical function binding of SYMBOL
(such as that done by FLET or MACROLET) surrounding the body.
Test Case:
(defun ff (x y) (list x y))
(defun op (object)
(symbol-macroflet ((f (lambda (x) (ff object x))))
(list (f 1) (f 2))))
is equivalent to
(defun op (object)
(list ((lambda (x) (ff object x)) 1) ((lambda (x) (ff object x)) 2)))
Rationale:
This satisfies the stated goals.
In principle, it would seem as if FLET be used. It has equivalent
expressional power, but in practice the compiler in most implementations
expects that local functions declared in FLET and LABELS will actually
be used in the body. Some implementations even complain when the functions
are not used.
To get around the expectation that FLET functions will be used, it may
be necessary to do
(FLET ((F ...)) #'F ...)
to make sure F gets used, but then some compilers do not optimize that
idiom -- sometimes just producing unreachable code, sometimes even consing
a gratuitous closure.
FLET with INLINE declarations cannot be depended upon portably because
there is no requirement that every implementation support the INLINE
declaration in a serious way.
MACROLET cannot be used because #'symbol would not be possible.
The only other option is to write a code-walker, but that option has been
pretty much shot to bits in the analogous argument about SYMBOL-MACROLET.
Current Practice:
Symbolics Cloe has this primitive internally (called SYMBOL-FMACROLET).
It has been used successfully to implement support for DEFUN-IN-FLAVOR,
producing a noticeable improvement in compilation-speed.
Cost to Implementors:
Once you're dealing with SYMBOL-MACROLET, this is little extra effort.
Cost to Users:
None. This extension is compatible.
Cost of Non-Adoption:
A portable compatibility package for Flavors would be difficult to
provide in a way that was both fully portable and reliably efficient.
Benefits:
Other applications involving macros that must introduce FLET bindings
which might not get used might be sped up by converting to this
primitive.
Some code could be made faster in implementations which did not
support the INLINE declaration for FLET'd functions by switching to
this primitive.
Aesthetics:
This extension corrects the asymmetry in functionality introduced with
SYMBOL-MACROLET.
Discussion:
Pitman supports this extension.
∂30-Sep-88 1554 CL-Cleanup-mailer Re: Issue: KILL-PACKAGE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 15:54:24 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 30 SEP 88 15:25:34 PDT
Date: 30 Sep 88 15:25 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: KILL-PACKAGE (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 30 Sep 88 17:17 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880930-152534-1216@Xerox>
I'm suprised this issue makes no mention of DELETE-PACKAGE or why it won't do.
∂30-Sep-88 1753 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 30 Sep 88 17:52:59 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01093g; Fri, 30 Sep 88 16:50:42 PST
Received: by blacksox id AA00573g; Fri, 30 Sep 88 17:47:28 pdt
Date: Fri, 30 Sep 88 17:47:28 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810010047.AA00573@blacksox>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 30 Sep 88 18:47 EDT <880930184754.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROFLET (Version 1)
Since FLET is sufficient for this purpose, I see no need to add this
to the language. Complain to your Common Lisp supplier if you are
having problems with run-time performance, compile-time performance,
or undesirable warnings.
∂30-Sep-88 1804 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 18:00:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 SEP 88 17:48:20 PDT
Date: 30 Sep 88 17:46 PDT
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Message-ID: <880930-174820-1519@Xerox>
I added a reference to FUNCTION-TYPE, since before FUNCTION-TYPE,
(DECLARE (TYPE FUNCTION X Y Z)) didn't make much sense.
I edited the discussion to remove the references to older versions
of the issue that we aren't distributing.
I changed the problem description a bit.
I changed it from "Walter thinks ...." to "It is possible that ...." in the discussion;
I hope that's OK.
OK?
!
Issue: DECLARE-FUNCTION-AMBIGUITY
References: CLtL pp 43 (Table 4-1), 158-159
Issue FUNCTION-TYPE (passed X3J13/June 1988)
Category: CHANGE
Edit history: #1, 21 Sept 1988, Walter van Roggen
#2, 29 Sept 1988, Walter van Roggen (renamed; lessened ambiguity)
#3, 30-Sep-88, Masinter
Problem description:
CLtL permits confusing and ambiguous FUNCTION declarations. One can say
(DECLARE (FUNCTION F (VECTOR INTEGER) T))
to indicate that the function binding for F is of a certain type. Yet
one can also say
(DECLARE (FUNCTION X Y Z))
to indicate that the variables X, Y, and Z have values which are functions.
The former is an abbreviation for
(DECLARE (FTYPE (FUNCTION (VECTOR INTEGER) T) F))
The latter is an abbreviation for
(DECLARE (TYPE FUNCTION X Y Z))
The ambiguity arises in a case like
(DECLARE (FUNCTION F NIL STRING))
However, it would be an error to declare the type of the constant NIL to be a
FUNCTION, so technically there is no ambiguity--there is just a peculiar
special case.
Using the same declaration for two completely different purposes can lead
to confusion among people writing or reading such code.
It is now more useful to declare that variables have a value which
is of type FUNCTION, since the type FUNCTION has a more well-specified
meaning.
Proposal (DECLARE-FUNCTION-AMBIGUITY:DELETE-FTYPE-ABBREVIATION)
The declaration (FUNCTION name argtypes valtypes) is no longer permitted
to be an abbreviation for (FTYPE (FUNCTION argtypes valtypes) name).
The declaration (FUNCTION var1 var2) would just be an abbreviation for
(TYPE FUNCTION var1 var2).
Rationale:
Continuing to allow all the predefined atomic type specifiers as declaration
abbreviations for (TYPE type var1 var2 ...) is simpler for users to understand.
In other words, all the normal type declarations describe variable bindings;
only the FTYPE declaration describes function bindings. This is a more
uniform solution than making an exception to table 4-1.
Since the old use of the FUNCTION declaration for function bindings was just
an abbreviation for the FTYPE declaration, no expressivity is lost.
Furthermore one is able to say that a variable's value is of type FUNCTION,
something that hadn't been clearly possible without using the TYPE declaration.
Current Practice:
Many current implementations treat FUNCTION declarations
only as abbreviations for FTYPE declarations, primarily because
the proposal FUNCTION-TYPE has not been widely implemented.
Cost to Implementors:
Likely to be small to those implementations that heed these kinds of
declarations; none for those that don't.
Cost to Users:
Existing uses of the FUNCTION declaration for function bindings will need
to be changed to FTYPE declarations.
Cost of Non-Adoption:
People will continue to be confused by function declarations.
Benefits:
A simpler language.
Esthetics:
Discussion:
Making it clear that only FTYPE declarations describe function bindings will
make it easier to add new kinds of declarations that support incremental or
additional descriptions, as is needed for describing methods.
Since all cases can be disambiguated after all, compatibility considerations
might deem this proposal to be unnecessary. However, making declarations
simpler and less confusing is possibly more important than compatibility.
∂30-Sep-88 2135 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 21:35:24 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 SEP 88 21:33:54 PDT
Date: 30 Sep 88 21:33 PDT
From: masinter.pa@Xerox.COM
to: cl-cleanup@sail.stanford.edu
Subject: Issue: DECLARE-TYPE-FREE (Version 5)
Message-ID: <880930-213354-1766@Xerox>
I added my reaction JonL's comment about nested types to the discussion
section. I also mentioned in the "Cost to Implementors" the possibility
that it might be necessary to remove error checks.
I think this is ready for release. Complain soon if you don't.
!
Issue: DECLARE-TYPE-FREE
References: CLtL p.158
DECLARATION-SCOPE
Category: CLARIFICATION/ADDITION
Edit history: Version 1, 18-Sep-88, Moon
Version 2, 22-Sep-88, Moon
(small edits to reflect mail discussion)
Version 3, 22-Sep-88, Masinter
Version 4, 27-Sep-88, JonL
Version 5, 30-Sep-88, Masinter (cost to implementors)
Problem description:
Section 9.2 of CLtL, p158, says that a declaration specifier like
(TYPE type var1 var2 ...) "... affects only variable bindings".
Since declarations can occur in contexts other than establishing
"variable bindings", most people interpret this statement to mean
that type declarations not in such context are either (1) completely
to be ignored, or (2) invalid CL syntax. Thus both of the following
forms would be suspect in that the type declarations could not have
any effect:
(if (and (typep x 'fixnum) (typep y 'fixnum))
(locally (declare (fixnum x y)) ;LOCALLY does not bind
...algorithm using x and y...) ; any variables.
...similar algorithm using x and y...)
(let ((y 'foo))
(setq y 10)
(let ((x 5)) ;'y' is not being bound in
(declare (fixnum y)) ; this particular context.
(incf y)
...random algorithm...))
Proposal (DECLARE-TYPE-FREE:ALLOW):
Avoid the phrase "affects only variable bindings". Clarify that a type
declaration means that it is an error for the value of the variable not
to be a member of the declared type, within the scope of the declaration.
Clarify that the above programs are valid, and that this kind of
declaration means the same thing as wrapping a THE form around every
reference to the variable, including modifying references by setq or
setf.
Clarify that if nested type declarations refer to the same variable, then
the value of the variable must be a member of the intersection of the
declared types.
Rationale:
It enables optimizing compilers to make use of the otherwise ignored
type information. Many people have often asked for it, and there is
no strong reason to forbid it.
Current practice:
Lucid implements DECLARE-TYPE-FREE:ALLOW already; but under some
circumstances the compiler issues a warning message that such usage
is an extension to Common Lisp.
Cost to Implementors:
Implementations that might currently warn about such declarations
would have to remove the warning; otherwise, it is valid to ignore
type declarations.
Cost to Users:
None, this is a compatible addition.
Cost of non-adoption:
Common Lisp will be less self-consistent.
Benefits:
Programmers will be able to use type declaration to express their
intent, rather than having to manually insert THE wrappers around
every reference.
Esthetics:
It is a simpler interpretation for type declaration specifiers, with
fewer special cases; hence reduces the number of exceptions in the
language.
Discussion:
Another cleanup issue, DECLARATION-SCOPE, addresses the scope of
declarations. This proposal carefully uses the phrase "within the
scope of the declaration" to avoid confounding the two issues.
This issue has been discussed at the Fort Collins X3J13 meeting in
November 1987, and at length on the various electronic mailing lists.
At least one current implementation is able to generate more efficient
code when declarations are associated with a particular binding, since
it then has the option to choose type-specific specialized storage for
the runtime value of the variable. So, for example,
(let ((x v)) (declare (type float x)) (+ x x))
is sometimes more efficient than
(let ((x v)) (locally (declare (type float x)) (+ x x)))
However, the local type declarations allowed by this proposal do
provide some useful information, even if it is not the *most* useful.
It is possible for a sufficiently "smart" compiler to infer the
equivalent of a "binding declaration" when it can ascertain that the
type of the binding value -- 'v' above -- is commensurate with the
type locally declared over the scope of usage of the variable.
It may be useful for a compiler to issue a warning whenever it finds
nested type declarations referring to the same variable and the
intersection of the declared types is null.
A style note might add that since nested type declarations intersect,
it would be bad style to have inner declarations be subtypes of the outer
ones. For example
(locally (declare (type x fixnum))
(locally (declare (type x (or bit package)))
(setq x 1)))
would be confusing. Such code might be generated by macros, however.
∂30-Sep-88 2213 CL-Cleanup-mailer Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 30 Sep 88 22:13:37 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 30 SEP 88 22:08:44 PDT
Date: 30 Sep 88 22:08 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2)
To: CL-Cleanup@SAIL.STANFORD.EDU
line-fold: NO
Message-ID: <880930-220844-1787@Xerox>
OK, I picked LIKE-ENCODE and tried out a couple of other implementations.
Ready? (NACKs only)
!
Issue: DECODE-UNIVERSAL-TIME-DAYLIGHT
References: DECODE-UNIVERSAL-TIME (p445)
Category: CLARIFICATION
Edit history: 20-Jun-88, Version 1 by Pitman
30-Sep-88, Version 2 by Masinter
Problem Description:
The description of DECODE-UNIVERSAL-TIME does not say what happens with
TIME-ZONE. Since the description of ENCODE-UNIVERSAL-TIME mentions that
its behavior differs depending on whether a time zone is explicitly passed,
some implementors may have assumed that DECODE-UNIVERSAL-TIME should do
likewise.
Even if all implementations did the same thing, it should still be clarified
whether an implementation were permitted to return dsp=NIL tz=n rather than
dsp=T tz=n+1 for time zones in which daylight savings time was believed to
be (or known to be) in effect. Currently, you cannot tell whether "NIL" for
daylight-savings-time-p means "daylight savings time is in effect" or
just "daylight savings time is not known to not be in effect".
These tools appear to be more portable than they are.
Proposal (DECODE-UNIVERSAL-TIME-DAYLIGHT:LIKE-ENCODE):
Specify that, like ENCODE-UNIVERSAL-TIME, DECODE-UNIVERSAL-TIME ignores
daylight savings information if a timezone is explicitly specified.
Rationale:
This makes things consistent with ENCODE-UNIVERSAL-TIME.
Test Case:
;; ### This test case relies on time zone not changing in real
;; ### time, in defiance of warning in note at bottom
;; ### of p445.
(LET* ((HERE (NTH 8 (MULTIPLE-VALUE-LIST (GET-DECODED-TIME)))) ;Time zone
(RECENTLY (GET-UNIVERSAL-TIME))
(A (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY))))
(B (NTHCDR 7 (MULTIPLE-VALUE-LIST (DECODE-UNIVERSAL-TIME RECENTLY HERE)))))
(LIST A B (EQUAL A B)))
Under this proposal, this would return ((T 5) (NIL 5) NIL) in EDT, for example.
Current Practice:
Symbolics Genera, Symbolics Cloe, Lucid 3.0 and Envos Medley seem to implement this proposal. Some other implementations do not.
Cost to Implementors:
The cost of changing this should be trivial.
Cost to Users:
This feature is already not well-defined since no portable program can rely
on the current behavior, so the cost is small.
Cost of Non-Adoption:
The time primitives are considerably less useful if this point is not
clearly spelled out.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Anything that improves the intelligibility of language primitives improves
language aesthetics.
Discussion:
An alternative would be to specify that, unlike ENCODE-UNIVERSAL-TIME,
DECODE-UNIVERSAL-TIME treats daylight savings information the same
regardless of whether a time zone argument is explicitly or not. This seems
actually to be what was intended originally.
This problem arose while trying to port Macsyma between different
Common Lisp implementations. The cleanup committee does not have
a strong opinion on this matter, as long as the behavior is specified.
∂01-Oct-88 0156 CL-Cleanup-mailer Issue: DEFPACKAGE (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Oct 88 01:55:50 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 OCT 88 01:22:10 PDT
Date: 1 Oct 88 01:22 PDT
From: masinter.pa@Xerox.COM
To: CL-Cleanup@Sail.stanford.edu
Subject: Issue: DEFPACKAGE (version 4)
Message-ID: <881001-012210-1872@Xerox>
Well, I did some surgery to this, some of which you might not like:
I moved the rationale that was in the proposal down to the Rationale section.
I made some minor changes in various parts of the proposal,
(e.g., "give Common Lisp a bad name" =>
"frustrate programmers")
I removed the part about MAKE-PACKAGE taking the same keywords.
It didn't seem well motivated to me, and I thought could be a separate proposal.
I shortened the proposal by saying once that package-name and symbol-name
could be symbols but only the symbol-name is used.
!
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating programmers.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol,
only its name matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below.
Each option may appear at most once. If duplicate options are present,
DEFPACKAGE signals an error.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
Inherit from the specified packages.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined, and
place them on the shadowing symbols list.
(:SHADOWING-IMPORT-FROM {(package-name {symbol-name}*)}*)
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified packages and import
them into the package being defined, and place them on the
shadowing symbols list. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible for
one of the names in its corresponding "from" package. The second
syntax is simply a convenient abbreviation when only one package
is specified.
(:IMPORT-FROM {(package-name {symbol-name}*)}*)
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified packages and import
them into the package being defined. Each 'symbol-name' argument
must be either a string or a symbol. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible for
one of the names in its corresponding "from" package. The second
syntax is simply a convenient abbreviation when only one package
is specified.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
intern'ing will merely access an already imported symbol.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
The collection of symbol-name arguments given to the options :SHADOW,
:IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be disjoint; an error
is signalled otherwise. In a chronological sense, the :EXPORT may be
thought of as ocurring last so that it can make reference to inherited
or imported symbols already created by the other three options.
DEFPACKAGE creates the package as specified, and returns it as its
value. It has no other side effects; i.e., it does not do an IN-PACKAGE.
Examples:
;;; Play it super-safe, and use only strings as names; do not even assume
;;; assume that the package it is read in to "uses" LISP; do *not* create
;;; any symbols whatsoever in the package that it is read in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, using symbols rather than strings as names; expects
;;; to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(DEFPACKAGE MY-PACKAGE
(:NICKNAMES MYPKG :MY-PKG)
(:USE LISP)
(:SHADOW CAR :CDR #:CONS)
)
Rationale:
The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time.
Cost to Implementors:
Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be subject of a separate cleanup.
The macroexpansion of DEFPACKAGE should be permitted to canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
Additional options might be present in an implementation; implementations
should probably signal an error if an option not recognized by that implementation is
present.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
∂01-Oct-88 1338 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 13:38:35 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468860; Sat 1-Oct-88 16:37:11 EDT
Date: Sat, 1 Oct 88 16:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 5)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880930-213354-1766@Xerox>
Message-ID: <881001163641.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 30 Sep 88 21:33 PDT
From: masinter.pa@Xerox.COM
...
I think this is ready for release. Complain soon if you don't.
Sorry, but I have two comments which I think should be addressed before
this goes out.
Issue: DECLARE-TYPE-FREE
...
Discussion:
...
A style note might add that since nested type declarations intersect,
it would be bad style to have inner declarations be subtypes of the outer
ones. For example
(locally (declare (type x fixnum))
(locally (declare (type x (or bit package)))
(setq x 1)))
would be confusing. Such code might be generated by macros, however.
This example is buggy because the syntax of TYPE declarations should have
the type first and the variable second. You want
(TYPE FIXNUM X)
and
(TYPE (OR BIT PACKAGE) X)
respectively.
Anyway, I find this remark about the style note confusing. FIXNUM is not
a subtype of (OR BIT PACKAGE) nor vice versa. There are two cases of
interest:
- The outer declaration is a subtype of the inner. eg,
(LOCALLY (DECLARE (TYPE FIXNUM X))
(LOCALLY (DECLARE (TYPE NUMBER X))
...))
which is redundant but harmless. I don't think it's anything to
stylistically discourage though.
- The outer declaration is not a subtype of the inner, and vice versa.
That is, the two types only partly overlap (or don't overlap at all).
You've already discussed the case of no overlap above in the Discussion,
so there's no point in repeating the remarks here. Instead, I'd just
deal with your example, which illustrates the interesting case of
only partially overlapping types. The case is interesting, but I'm a
little worried even here that "bad style" translates to "a compiler
should warn about this" and since, as you say, a macro might legitimately
expand into this, I think it's a very bad idea to identify it as
bad style...
∂01-Oct-88 1357 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 13:57:10 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468864; Sat 1-Oct-88 16:55:57 EDT
Date: Sat, 1 Oct 88 16:55 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880930171700.1.KMP@GRYPHON.SCRC.Symbolics.COM>,
<881001-010107-1861@Xerox>,
<880930-152534-1216@Xerox>
Message-ID: <881001165530.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Changes made...
Renamed KILL-PACKAGE to DELETE-PACKAGE because some implementations
use that name already. [Genera doesn't use that name but will have
to change names anyway since no one is likely to buy into PKG-KILL.]
Very minor cosmetic edits to accomodate the renaming.
Added current practice based on mail from Masinter.
Changes not made ...
I left the topic name the same. Hopefully that won't confuse anyone.
Masinter suggested (privately) that this should permit a symbol
argument to designate package-name as well. I used the term
"package or package name". I'd rather have that mean whatever the
term "package name" means globally in the spec. If that includes
symbols (which is fine by me, then it should work here, too. But
we shouldn't have one function that permits symbols and a bunch
more that take only strings.
-----Modified Proposal Follows-----
Issue: KILL-PACKAGE
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (KILL-PACKAGE:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE names a package which does not exist, or is a package
object which has been deleted already, an error is signalled.
The name and nicknames of the designated package cease to be
recognized package names.
If the designated package is used by other packages, the effect of
UNUSE-PACKAGE is done to remove that dependency, causing its external
symbols to stop being accessible to those packages.
Any symbols in the designated package still exist after this function
is called. If their home package was not the package to be deleted, the
home package will be unchanged. If their home package was that package,
the home package after this operation is unspecified; the effect of
printing such symbols is also unspecified.
The designated package persists after this function is called.
PACKAGEP is still true of it, but PACKAGE-NAME will return NIL.
The effect of any other package operation on PACKAGE is undefined.
DELETE-PACKAGE returns T.
Test Case:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior.
When a package is killed the home package of all symbols in that package
are left undisturbed (i.e., local symbols pointing to the killed package).
Procyon Common Lisp has a DELETE-PACKAGE already. It differs in that it
signals an error if the package is used by another package. Procyon
returns the name of the package so deleted (as a string).
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Pitman supports this addition.
∂01-Oct-88 1521 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Oct 88 15:21:25 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 OCT 88 15:19:54 PDT
Date: 1 Oct 88 15:20 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EQUAL-STRUCTURE (Version 4)
TO: cl-cleanup@Sail.stanford.edu
cc: masinter.pa@Xerox.COM
LINE-FOLD: NO
Message-ID: <881001-151954-2189@Xerox>
JonL was right.. I tried to fix it. Ready for release?
!
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
8-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
1-Oct-88, Version 4 by Masinter (fix description)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, descends
the structure of arrays, defstruct and CLOS instances. It uses EQ
for all other types; for example, it does not descend hash tables.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives. Aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
We considered:
removing EQUAL and EQUALP from the standard.
changing EQUALP to descend structures.
changing EQUALP to be case sensitive.
adding a :TEST keyword to EQUAL.
making EQUAL a generic function
All of these had some serious problems.
∂01-Oct-88 1548 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 15:48:14 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468903; Sat 1-Oct-88 18:46:48 EDT
Date: Sat, 1 Oct 88 18:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 4)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881001-151954-2189@Xerox>
Message-ID: <881001184620.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Can we not say "CLOS instances" and just use "instances"? The single
word is not ambiguous now that CLOS is adopted. I don't want users of a
Flavors compatibility package to get worried that "CLOS instances" and
"Flavors instances" might be different. I'd rather the paragraph on
EQUALP read:
EQUALP is similar, except that it ignores case in strings,
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
I'd also like to add a paragraph like the following to the proposal
part. Anyone object or want to amend the wording?
Document that object equality is not a concept for which
there is a uniquely determined correct algorithm. The
appropriateness of an equality predicate can be judged only
in the context of the needs of some particular program.
Although these functions take any type of argument and
their names sound very generic, EQUAL and EQUALP are not
appropriate for every application. Any decision to use
or not use them should be determined by what they are
documented to do rather than any abstract characterization
of their function. If neither EQUAL nor EQUALP is found to
be appropriate in a particular situation, programmers are
encouraged to create another operator that is appropriate
rather than blame EQUAL or EQUALP for ``doing the wrong
thing.''
∂01-Oct-88 1608 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Oct 88 16:08:01 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 OCT 88 16:06:30 PDT
Date: 1 Oct 88 16:06 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: EXIT-EXTENT (Version 2)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881001-160630-2212@Xerox>
Sigh, I started to edit this with the idea that there were some minor
edits, and I discovered that the wording at least is awkward because GO
does a non-local transfer of control that is not an "exit" per se. (There
is something unnamed that GO exits, but to talk about the extent of it one
almost has to name it.)
It uses the phrase "The terms "normal exit", "target", and "passed over"
will be used with
these meanings for the remainder of the discussion." but doesn't really
ever say what "these meanings" are.
I started to edit it, but I'm afraid it needs more work than I have time
for right now. David, can you give it another shot? You can either start
with your version or this one. (I think I changed "Scheme ducks" to "Scheme
avoids" and made a few other conciliatory edits....)
!
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter
minor edits.
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK or TAGBODY,
or equivalent such as PROG.
(2) Nonlocal exit from the target of a THROW or RETURN or to
the target of a GO.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In cases 2 and 3, the extent could
end anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the shortest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the shortest extent consistent with CLtL maximizes freedom
for implementations; there are few applications for allowing a longer
extent.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target exit at the moment the values are returned, and end the
extent of a passed-over exit at the moment the THROW, RETURN, or GO
commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for
a throw or non-local exit to be effectively "stopped" by a UNWIND-PROTECT
clause.
Cost to Implementors:
No currently valid implementation will be made invalid by this proposal.
Some implementors may wish to add error checks if they do not already
have them.
Cost to Users:
Since this is a clarification and current implementations differ, this
issue
ostensibly does not affect current portable programs.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition will
be consistent with current practice in a way that has no cost for
implementors
nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
One aspect of this issue, namely the particular behavior of non-local
exits from unwind protect cleanup clauses, was discussed at great
length. Some of that discussion centered around the possibility of
creating "unstoppable loops" that could not be exited by constructs
like
(tagbody retry (unwind-protect .... (go retry)))
.
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal.
∂01-Oct-88 1612 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 1 Oct 88 16:12:11 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 01 OCT 88 16:10:33 PDT
Date: 1 Oct 88 16:10 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: EQUAL-STRUCTURE (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 1 Oct 88 18:46 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881001-161033-2214@Xerox>
I think there would be grounds for objection if the cleanup committee
started recommending that the standard document this or used particular
wording. I certainly wouldn't use an imperative "Document that ...." in the
cleanup proposal.
I would object to a statement in the Discussion section saying that
"It would be useful if descriptions of EQUAL and EQUALP
included notes to the effect that ..."
Since we're both on the Editorial committee, we can bring up there how it
might be most appropriate to get those kinds of notes into the standard
document and where it would be appropriate to put them.
OK?
Larry
∂01-Oct-88 1619 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 16:19:30 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468918; Sat 1-Oct-88 19:18:00 EDT
Date: Sat, 1 Oct 88 19:17 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EQUAL-STRUCTURE (Version 4)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881001-161033-2214@Xerox>
Message-ID: <881001191724.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 1 Oct 88 16:10 PDT
From: masinter.pa@Xerox.COM
... I would object to a statement in the Discussion ...
I assume you mean "wouldn't".
Ok, put it in the discussion. I'm not hot on making it imperative. I just
wanted it clearly marked for Kathy to find.
If you do that, and make the "instance" change, you can go ahead and count
me as supporting the proposal.
∂01-Oct-88 1640 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 16:40:44 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468922; Sat 1-Oct-88 19:39:29 EDT
Date: Sat, 1 Oct 88 19:39 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881001193901.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Per Masinter's request, here's a version with my comments edited in.
- Changed wording of EQUALP portion of Proposal to change
"CLOS instance" to "instance" and "defstruct instance" to "structure".
- Added Cleanup committee endorsement for option STATUS-QUO in Discussion.
- Added editorial advice in Discussion.
-----
Issue: EQUAL-STRUCTURE
References: EQUAL (p80), EQUALP (p81)
Category: CLARIFICATION/CHANGE
Edit history: 18-Mar-88, Version 1 by Pitman
08-Jun-88, Version 2 by Masinter (add Benson's proposal)
23-Sep-88, Version 3 by Masinter (remove all but STATUS-QUO)
01-Oct-88, Version 4 by Masinter (fix description)
01-Oct-88, Version 5 by Pitman (correct wording, add discussion)
Problem Description:
The behavior of EQUAL and EQUALP on structures is a subject of controversy.
At issue are whether these functions should descend the slots of structures
or use simply the structure's primitive identity (i.e., EQ) to test for
equivalence.
Proposal (EQUAL-STRUCTURE:STATUS-QUO):
Clarify that EQUAL and EQUALP do not descend any structures or
data types other than the ones explicitly specified in CLtL.
EQUAL uses EQL for numbers and characters, descends structure for CONSes
bit-vectors, strings; has special behavior for pathnames as specified
in CLtL, and uses EQ for all other types.
EQUALP is similar, except that it ignores case in strings, and it
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
Rationale:
There seem to be as many different equality primitives as there
are applications for them. None of the possible ways of changing
EQUAL or EQUALP are flawless. Given the inability to "fix" them,
it is better to leave them alone.
Current Practice:
We are unaware of any extensions to CLtL's set of operations,
although frequently users request them.
Cost to Implementors:
Since this seems to be compatible with the status quo, none.
Cost to Users:
Same
Cost of Non-Adoption:
Ongoing controversy about whether EQUAL and EQUALP "do the right thing".
Benefits:
A feeling that EQUAL and EQUALP exist and/or do what they do because serious
consideration was given and we consciously decided on a particular resolution
to the numerous questions that have come up about them.
Aesthetics:
There seems to be wide debate about what the proper aesthetics for
how equality should work in Common Lisp. While the status quo is not
aesthetically more pleasing than the various alternatives. Aesthetic
considerations vary widely. Different people model structures
differently. Sometimes the same person models structures differently in
different situations. The question of which should be descended and which
should not is a very personal one, and the aesthetic attractiveness of any
of these options will vary from person to person or application to
application.
Discussion:
An earlier version of this issue with various alternatives was distributed
at the June 1988 X3J13 meeting. Since
this is a frequently raised issue, we thought we should submit it
as a clarification although there is no change to CLtL.
Options for which we considered proposals were:
- removing EQUAL and EQUALP from the standard.
- changing EQUALP to descend structures.
- changing EQUALP to be case sensitive.
- adding a :TEST keyword to EQUAL.
- making EQUAL a generic function
All of these had some serious problems.
The cleanup committee supports option STATUS-QUO.
It would be useful if descriptions of EQUAL and EQUALP contained some sort
of additional commentary alluding to the complex issues discussed here.
The following is offered to the Editorial staff as a starting point:
Object equality is not a concept for which there is a uniquely
determined correct algorithm. The appropriateness of an equality
predicate can be judged only in the context of the needs of some
particular program. Although these functions take any type of
argument and their names sound very generic, EQUAL and EQUALP are
not appropriate for every application. Any decision to use or not
use them should be determined by what they are documented to do
rather than any abstract characterization of their function. If
neither EQUAL nor EQUALP is found to be appropriate in a particular
situation, programmers are encouraged to create another operator
that is appropriate rather than blame EQUAL or EQUALP for ``doing
the wrong thing.''
∂01-Oct-88 1709 CL-Cleanup-mailer Issue: ALIST-NIL (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 17:09:11 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468927; Sat 1-Oct-88 20:08:00 EDT
Date: Sat, 1 Oct 88 20:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ALIST-NIL (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880921-013345-5657@Xerox>
Message-ID: <881001200733.0.KMP@GRYPHON.SCRC.Symbolics.COM>
The discussion following this proposal showed that NIL did have more
purpose in an a-list than my "problem description" had suggested, yet
my biased writeup had persisted through three revisions. In spite of
the "good uses" people have suggested, I still support my proposal,
but I felt enough guilty that I rewrote the proposal to try to at
least remove my original bias and present the issue fairly.
-----
Issue: ALIST-NIL
References: Definition of "a-list" (p279), ASSOC (p280)
Category: CHANGE
Edit history: 20-Jun-88, Version 1 by Pitman
04-Sep-88, Version 2 by Masinter (reflect discussion)
21-Sep-88, Version 3 by Masinter (minor edits)
01-Oct-88, Version 4 by Pitman (remove some bias)
Problem Description:
NIL is permitted to be an element of an a-list but very little of
use can be done with such an element, and the idea can be confusing.
In most situations where an a-list entry is to be removed, it is
done by straightfoward uses like
(SETQ THE-ALIST (REMOVE THE-ENTRY THE-ALIST))
or (SETQ THE-ALIST (DELETE THE-ENTRY THE-ALIST)).
Relatively few situations require the more advanced technique of
(SETF (CAR THE-ALIST-TAIL) NIL)
in order to remove an entry from a list. Usually these situations
involve multiple pointers into different parts of the same a-list,
or very long a-lists where DELETE or REMOVE would take a long time.
Proposal ALIST-NIL:DISALLOW:
Change the definition of an a-list to require all elements to be
real conses. Uses of ASSOC with non-standard a-list would be an error.
Test Case:
(ASSOC 'X '(NIL (X . 3)))
is currently defined to return (X . 3).
Under this proposal, this would be an error.
Rationale:
An a-list is a commonly used data structure that should be easy to
explain. Permitting NIL in an a-list complicates the description
considerably.
This change would make the relationship between FIND (with key of
#'CAR) and ASSOC simpler and easier to explain.
Current Practice:
All valid implementations permit NIL in an a-list.
Cost to Implementors:
Since the proposal is to make this an "is an error" situation, no
implementation would be forced to change.
Cost to Users:
There are two basic ways in which we expect this feature is used
currently.
#1: A user wants a leading NIL on an a-list so that if the list
is empty, there's still be a tail to which cells could be
attached in the future. That is,
(DEFVAR *MY-ALIST* (CONS NIL '()))
so that
...(NCONC *MY-ALIST* (LIST new-cell))...
would always be possible as a side-effect and
...(ASSOC element *MY-ALIST*)...
would always be possible for lookup. It might be argued that
this is more clearly written:
(DEFVAR *MY-TABLE* (CONS NIL '()))
(DEFUN ADD-ENTRY (ENTRY TABLE) (NCONC TABLE (LIST ENTRY)))
(DEFMACRO MY-TABLE-CONTENTS (X) `(CDR ,X))
...(ADD-ENTRY new-cell *MY-TABLE*)...
...(ASSOC element (MY-TABLE-CONTENTS *MY-TABLE*))...
#2: A user might want to splice out an element from an a-list, preserving
the place that the element occupied in the list. In the very rare cases
where this was necessary, one could rewrite:
(DEFUN VOID-FIRST-ENTRY (ALIST) (SETF (CAR ALIST) NIL))
as:
(DEFUN VOID-FIRST-ENTRY (ALIST)
(LET ((ENTRY (CONS NIL NIL)))
(SETF (CAR ENTRY) (GENSYM)) ;or ENTRY or something otherwise unique
(SETF (CAR ALIST) ENTRY)))
This might change the behavior of ASSOC-IF, ASSOC-IF-NOT, RASSOC-IF
and RASSOC-IF-NOT depending on the predicate used.
Also, in this case, the user must also consider that whatever is used
as the unique key must be acceptable to ASSOC.
In rare cases where neither of these rewrites were acceptable, the user could
still write his own variant of ASSOC to handle NIL even if the system version
did not.
Cost of Non-Adoption:
The only consequence of non-adoption is the burden of carrying around
the additional complexity in each implementation, in the documentation,
and in teaching. The cost of this burden is likely to be a subjective
matter.
Benefits:
FIND (with a :KEY of #'CAR) and ASSOC (with no key) would be identical.
Aesthetics:
This change would simplify the language.
Discussion:
The description of association lists is currently cluttered by this
unmotivated feature; no strong motivation or widespread use
of the feature has been found.
Some people consider this change gratuitous.
The cleanup committee discussed some interesting optimizations
of ASSOC where the existing situation (special-casing NIL) didn't
actually cost in performance (at least in the special case where
the predicate was EQ or EQL), so performance issues were dismissed
as a rationale for this change.
∂01-Oct-88 1748 CL-Cleanup-mailer Issue: NTH-VALUE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 17:47:59 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468941; Sat 1-Oct-88 20:46:43 EDT
Date: Sat, 1 Oct 88 20:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: NTH-VALUE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8808162243.AA06571@mist.UUCP>
Message-ID: <881001204614.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Very minor changes per discussion...
- expanded the Problem Description slightly.
- changed Proposal to be more explict about order of argument evaluation
- minor reformatting and rewording in places to make things clearer
and/or remove first-person usages from Pierson's writeup.
-----
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
Status: For Internal Discussion
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
No implementation is known to provide this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Most will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
None, this is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
Pitman, Pierson, and Masinter have voiced support for this
proposal.
vanRoggen and Fahlman don't really think this feature is
necessary, but don't actively oppose its inclusion.
∂01-Oct-88 1749 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Oct 88 17:49:41 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01458g; Sat, 1 Oct 88 16:47:23 PST
Received: by bhopal id AA08601g; Sat, 1 Oct 88 17:46:55 PDT
Date: Sat, 1 Oct 88 17:46:55 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810020046.AA08601@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 30 Sep 88 17:17 EDT <880930171700.1.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 1)
Oh, foo, I'm afraid this will have to be called DELETE-PACKAGE.
The name DELETE-PACKAGE was reached by consensus on the common-lisp
mailing list around late spring 1985, and Lucid Common Lisp has had
it ever since. VAXLISP version V2.2 also uses this name.
It is also one of Guy Steele's "Clarifications" from 6-Dec-85
It was also on the hardcopy sheet of "possible proposals of concern
to Lucid" that I handed out to members of the subcommittee present
at the PaloAlto meeting earlier this year [but indeed, you weren't
bodily present -- I seem to remember a telephone and speaker phone
-- so maybe you didn't get a copy.]
Now as to the operation of DELETE-PACKAGE, it differs from your
proposal on the matter of what to do when some other packages are
"using" the one to be deleted. Steele says "signal an error";
Lucid Common Lisp signals a continuable error, and going on will
remove the links.
Although LCL signals an error if the argument isn't a package, it
silently returns NIL if the argument is an already de-registered
package. Eric Benson convinced me at one point in time that all
the the deletors should simply return NIL if they can't do their
deletory action; this includes giving it totally wrong data.
How would you feel about that approach?
-- JonL --
∂01-Oct-88 1809 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 1 Oct 88 18:09:06 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 468953; Sat 1-Oct-88 21:07:31 EDT
Date: Sat, 1 Oct 88 21:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 1)
To: jonl@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810020046.AA08601@bhopal>
Message-ID: <881001210701.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: Sat, 1 Oct 88 17:46:55 PDT
From: Jon L White <jonl@lucid.com>
Oh, foo, I'm afraid this will have to be called DELETE-PACKAGE.
This part is already dealt with. Your message and my corrected
proposal (Version 2) probably crossed in the mail.
...
Now as to the operation of DELETE-PACKAGE, it differs from your
proposal on the matter of what to do when some other packages are
"using" the one to be deleted. Steele says "signal an error";
Lucid Common Lisp signals a continuable error, and going on will
remove the links.
Well, your stated behavior is at least conservative. Presumably this
means that no one has code the correct operation of which depends on
calling DELETE-PACKAGE on packages which are "in use", so making a
change won't break any of those programs.
I'm inclined to believe it's better to define a useful behavior here
because
- It's easy to test for that case and guard against it in the
cases that matter.
- It's a pain to do the bookkeeping that is otherwise required.
By the way, I kind of agree that it's a little weird to silently
remove the package from the using package's use list, but then again,
deleting a package is not something people do lightly. It turns out
that this situation happens to me on a regular basis, though, because
I often delete a whole bunch of packages, some of which use others.
In that case, I'm happy it doesn't complain about the ones that use
the others because a moment later I'm going to delete them anyway.
But, of course, that's just one data point.
Although LCL signals an error if the argument isn't a package, it
silently returns NIL if the argument is an already de-registered
package.
I guess we're both inconsistent on this. Probably it should either
signal errors about all kinds of things or be tolerant about all kinds
of things...
Eric Benson convinced me at one point in time that all
the the deletors should simply return NIL if they can't do their
deletory action; this includes giving it totally wrong data.
How would you feel about that approach?
I'm not really opposed to it, but I'd be curious to get some viewpoints
from people outside of Lucid and Symbolics who have no vested stake in
this and are listening to evaluating these issues for the first time.
I'll think about putting out a compromise proposal based on this
discussion and any other feedback I get in the next day or two.
∂01-Oct-88 2055 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Oct 88 20:55:49 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01494g; Sat, 1 Oct 88 19:53:37 PST
Received: by bhopal id AA08953g; Sat, 1 Oct 88 20:53:11 PDT
Date: Sat, 1 Oct 88 20:53:11 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810020353.AA08953@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@Sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 1 Oct 88 15:20 PDT <881001-151954-2189@Xerox>
Subject: Issue: EQUAL-STRUCTURE (Version 4)
re: EQUALP is similar, except that it ignores case in strings, descends
the structure of arrays, defstruct and CLOS instances. It uses EQ
for all other types; for example, it does not descend hash tables.
Hmmm, wanna try one more time? This needs to say "uses = for numbers,
and uses eql for characters".
Also John Rose made what I thought was a good suggestion -- that some
extended equality predicate treat hash tables as "objects that have
components" (see CLtL p81), and that the correspondence be based on
the hash tables' keys. If you merely want to describe the status quo,
I think you have to say this point has not been clear, and cannot be
depended upon in any current implementation.
re: We considered:
removing EQUAL and EQUALP from the standard.
changing EQUALP to descend structures.
changing EQUALP to be case sensitive.
adding a :TEST keyword to EQUAL.
making EQUAL a generic function
I think it should say that we considered
changing EQUAL to descend structures.
rather than EQUALP. [If we didn't consider it then, then throw out
the whole thing and lets start again.]
-- JonL --
∂01-Oct-88 2104 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Oct 88 21:04:17 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01501g; Sat, 1 Oct 88 20:01:57 PST
Received: by bhopal id AA08982g; Sat, 1 Oct 88 21:01:30 PDT
Date: Sat, 1 Oct 88 21:01:30 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810020401.AA08982@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Sat, 1 Oct 88 16:36 EDT <881001163641.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 5)
I agree with you that the "style" comment paragraph should be flushed.
re: "FIXNUM is not a subtype of (OR BIT PACKAGE) nor vice versa.
There are two cases of interest: ..."
- The outer declaration is a subtype of the inner. eg,
...
- The outer declaration is not a subtype of the inner, and vice versa.
That is, the two types only partly overlap (or don't overlap at all).
...
Well, foo, in a previous message I claimed that the only legitimate case
is when the inner declaration is a subtype of the outter; that is a
third case you didn't cover. I think it was Gray's suggestion that
we generalize this strict restraint into permitting an inner declaration
to merely have a non-null intersection. But I don't see the value of
it, and it even prevents a certain amount of "strong typing" error
checking.
-- JonL --
∂01-Oct-88 2130 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 1 Oct 88 21:30:31 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01513g; Sat, 1 Oct 88 20:28:12 PST
Received: by bhopal id AA09036g; Sat, 1 Oct 88 21:27:45 PDT
Date: Sat, 1 Oct 88 21:27:45 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810020427.AA09036@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Sat, 1 Oct 88 18:46 EDT <881001184620.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 4)
re: I'd also like to add a paragraph like the following to the proposal
part. Anyone object or want to amend the wording?
Document that object equality is not a concept for which
there is a uniquely determined correct algorithm. ...
. . .
I object. (but take that with a smile!)
Let's just say that there are numerous equivalence relations that can
be defined on data strucures as rich as those available in Common Lisp,
and that EQL, EQUAL and EQUALP are merely three historically important
relics. Phrases that tend to imply that "object equality" is not a
"correct" concept, just don't belong in the language specification.
One *might* need to remind the lang. spec. reader
(1) just what an equivalence relation is;
(2) that EQ has the maximal number of equivalence classes;
(3) and that as relations, EQ is a subset of EQL, EQL is a subset
of EQUAL, and EQUAL is a subset of EQUALP.
-- JonL --
∂02-Oct-88 0844 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 2 Oct 88 08:42:10 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa03613; 2 Oct 88 15:37 BST
Date: Sun, 2 Oct 88 16:19:12 BST
Message-Id: <4933.8810021519@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: EQUAL-STRUCTURE (Version 4)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, KMP@scrc-stony-brook.arpa,
Masinter.PA@xerox.com
In-Reply-To: Kent M Pitman's message of Sat, 1 Oct 88 18:46 EDT
Cc: CL-Cleanup@sail.stanford.edu
> Can we not say "CLOS instances" and just use "instances"? The single
> word is not ambiguous now that CLOS is adopted. I don't want users of a
> Flavors compatibility package to get worried that "CLOS instances" and
> "Flavors instances" might be different.
I'm inclined to agree that "instances" is better, but Kent's reason
makes me wonder. Suppose someone implements an object system where
is isn't possible to descend instances (perhaps they're closures).
I don't think we can say they can't be called "instances". What it
would come down to would be that they weren't implemented as CLOS
instances and so the clause in EQUALP didn't apply.
So we want to say "instances", we have to say somewhere what "instance"
means in Common Lisp, and then it will be those instances we'll be talking
about in EQUALP.
It would then be up to the documentation for Flavors compatibility
packages and the like to how their concept of instances maps onto
Common Lisp. And I think that is how it should be.
So I agree with the first reason (it's no longer ambiguous), but
not the second.
∂02-Oct-88 1135 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Oct 88 11:35:23 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA01597g; Sun, 2 Oct 88 10:33:05 PST
Received: by blacksox id AA00623g; Sun, 2 Oct 88 11:30:37 pdt
Date: Sun, 2 Oct 88 11:30:37 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810021830.AA00623@blacksox>
To: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros,
Issue MACRO-FUNCTION-ENVIRONMENT,
Issue GET-SETF-METHOD-ENVIRONMENT,
Issue COMPILE-FILE-ENVIRONMENT,
Issue LOAD-TIME-EVAL
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Status: For internal discussion
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
Implementing the FIND-CLASS and ENSURE-GENERIC-FUNCTION functions of
CLOS requires the ability to distinguish between environments used
for compiling to a file from those used for processing in-core, such
as by EVAL or COMPILE. Resolution of the LOAD-TIME-EVAL issue may
also require this information. This problem has been addressed by
the recent cleanup issue COMPILE-FILE-ENVIRONMENT. Also, it has
proven impossible to write a portable code walker in Common Lisp, due
to insufficient access to the information contained in environments
and the inability to augment environments with local function
definitions.
Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):
The following functions provide information about syntactic
environment objects. In all of the functions the argument named ENV
is a environment, of the sort received by the &ENVIRONMENT argument
to a macro. In all cases it is an error to supply an argument which
is not a syntactic environment.
Note that we have used the term "syntactic environment" here. This
is to distinguish these environments from the environment arguments
of EVALHOOK and APPLYHOOK. EVALHOOK-type environments must include a
mapping from names to values (run-time) as well as the simple
presence-or-absence information (compile-time) needed for
MACROEXPAND-type environments. We consider these to be two entirely
different kinds of objects and will not deal with EVALHOOK-type
environments at all in this proposal.
ENVIRONMENT-TARGET env [Function]
This function returns one of the three symbols EVAL, COMPILE or
COMPILE-FILE, depending on whether the environment is from the
interpreter, the in-core compiler, or the file compiler. If
MACROEXPAND or MACROEXPAND-1 is called directly without supplying
the environment argument, the environment passed to any expander
functions will have target EVAL.
ENVIRONMENT-VARIABLE-KIND variable env [Function]
VARIABLE is a symbol. This function returns one of the following
values:
NIL, if the symbol has no visible definition, declaration or
binding as a variable.
PROCLAIM, if the symbol has been proclaimed special.
DECLARE, if the symbol has been declared special.
SYMBOL-MACROLET, if the symbol names a symbol macro.
T, if the symbol has an ordinary lexical binding.
[Note: these alternatives may have to be changed depending on the
outcome of the PROCLAIM-LEXICAL issue.]
Example:
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(ENVIRONMENT-VARIABLE-KIND VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (PROCLAIM T DECLARE SYMBOL-MACROLET NIL)
ENVIRONMENT-FUNCTION-KIND function env [Function]
FUNCTION is a symbol. This function returns one of the following
values:
NIL, if the symbol has no visible function definition or
function binding.
DEFUN, if the symbol names a global function not overridden by a
local binding.
DEFMACRO, if the symbol names a global macro not overridden by a
local binding.
SPECIAL-FORM-P, if the symbol names a special form.
FLET, if the symbol has a local function binding, such as
created by FLET or LABELS.
MACROLET, if the symbol has a local macro binding, such as
created by MACROLET.
Example:
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(ENVIRONMENT-FUNCTION-KIND FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(LIST (KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (DEFUN DEFMACRO SPECIAL-FORM-P FLET MACROLET NIL)
ENVIRONMENT-BLOCK-P block-name env [Function]
BLOCK-NAME is a symbol. This function returns T if there is a block
with that name in the environment, otherwise it returns NIL.
Example:
(DEFMACRO IS-A-BLOCK (NAME &ENVIRONMENT ENV)
`',(ENVIRONMENT-BLOCK-P NAME ENV))
(DEFUN TEST ()
(LOOP (RETURN (LIST (IS-A-BLOCK TEST)
(IS-A-BLOCK NIL)
(IS-A-BLOCK NOT-HERE)))))
(TEST) -> (T T NIL)
ENVIRONMENT-TAG-P tag-name env [Function]
TAG-NAME is a symbol or an integer. This function returns T if
there is a tag with that name in the environment, otherwise it
returns NIL.
Example:
(DEFMACRO IS-A-TAG (TAG-NAME &ENVIRONMENT ENV)
`',(ENVIRONMENT-TAG-P TAG-NAME ENV))
(DEFUN TEST ()
(PROG ()
A
(RETURN (LIST (IS-A-TAG A)
(IS-A-TAG I-HOPE-NOT)))))
(TEST) -> (T NIL)
ENVIRONMENT-VARIABLE-TYPE variable env [Function]
VARIABLE is a symbol. This function returns the type specifier
associated with the variable named by the symbol in the environment,
or NIL if there is none. (This is in spite of the fact that NIL is
a legal type specifier, since NIL has no meaning as a type specifier
for a variable.)
Example:
(DEFMACRO VARTYPE (VAR &ENVIRONMENT ENV)
`',(ENVIRONMENT-VARIABLE-TYPE VAR ENV))
(DEFVAR A 1)
(PROCLAIM '(FIXNUM A))
(DEFUN TEST ()
(LET ((B (AREF "X" 0))
(C 3))
(DECLARE (STRING-CHAR B))
(LIST (VARTYPE A) (VARTYPE B) (VARTYPE C))))
(TEST) -> (FIXNUM STRING-CHAR NIL)
ENVIRONMENT-FTYPE function env [Function]
FUNCTION is a symbol. This function returns the type specifier
associated with the function named by the symbol in the environment,
or NIL if there is none.
Example:
(DEFMACRO FUNTYPE (FUN &ENVIRONMENT ENV)
`',(ENVIRONMENT-FTYPE FUN ENV))
(DEFUN A-FUNCTION (X)
(+ X 3))
(PROCLAIM '(FTYPE (FUNCTION (FIXNUM) FIXNUM) A-FUNCTION))
(DEFUN TEST ()
(FLET ((ANOTHER-FUNCTION (X)
(+ X 2)))
(DECLARE (FTYPE (FUNCTION (INTEGER) INTEGER) ANOTHER-FUNCTION))
(LIST (FUNTYPE A-FUNCTION) (FUNTYPE ANOTHER-FUNCTION))))
(TEST) -> ((FUNCTION (FIXNUM) FIXNUM) (FUNCTION (INTEGER) INTEGER))
ENVIRONMENT-INLINE function env [Function]
FUNCTION is a symbol. This function returns INLINE, NOTINLINE or
NIL, depending on whether the function named by FUNCTION is declared
or proclaimed INLINE, declared or proclaimed NOTINLINE, or if no
such declaration or proclamation has been made.
Example:
(DEFMACRO INLINENESS (FUN &ENVIRONMENT ENV)
`',(ENVIRONMENT-INLINE FUN ENV))
(PROCLAIM '(INLINE A-SHORT-FUNCTION))
(DEFUN A-SHORT-FUNCTION () 'SHORT)
(PROCLAIM '(NOTINLINE Y))
(DEFUN Y (F)
((LAMBDA (G)
#'(LAMBDA (X)
(FUNCALL (FUNCALL F
(FUNCALL G G))
X)))
#'(LAMBDA (H)
#'(LAMBDA (Z)
(FUNCALL (FUNCALL F
(FUNCALL H H))
Z)))))
(DEFUN A-FUNCTION ())
(DEFUN TEST ()
(FLET ((A-LOCAL-FUNCTION ()))
(DECLARE (INLINE A-LOCAL-FUNCTION)
(NOTINLINE A-SHORT-FUNCTION))
(LIST (INLINENESS A-SHORT-FUNCTION)
(INLINENESS Y)
(INLINENESS A-LOCAL-FUNCTION)
(INLINENESS A-FUNCTION)))
(TEST) -> (NOTINLINE NOTINLINE INLINE NIL)
ENVIRONMENT-OPTIMIZE-LEVEL attribute env [Function]
ATTRIBUTE is one of the symbols SPEED, SPACE, SAFETY or
COMPILATION-SPEED. This function returns an integer between 0 and
3, which reflects the current settings of the OPTIMIZE proclamation
or declaration.
Example:
(DEFMACRO OPTIMIZE-LEVEL (PROPERTY &ENVIRONMENT ENV)
`',(ENVIRONMENT-OPTIMIZE PROPERTY ENV))
(PROCLAIM '(OPTIMIZE (SPEED 3)
(SAFETY 0)
(SPACE 0)
(COMPILATION-SPEED 0)))
(DEFUN TEST ()
(LIST (LIST (OPTIMIZE-LEVEL SPEED)
(OPTIMIZE-LEVEL SAFETY)
(OPTIMIZE-LEVEL SPACE)
(OPTIMIZE-LEVEL COMPILATION-SPEED))
(LOCALLY (DECLARE (OPTIMIZE (SAFETY 3)
(SPEED 0)
(COMPILATION-SPEED 3)
(SPACE 3)))
(LIST (OPTIMIZE-LEVEL SPEED)
(OPTIMIZE-LEVEL SAFETY)
(OPTIMIZE-LEVEL SPACE)
(OPTIMIZE-LEVEL COMPILATION-SPEED)))))
(TEST) -> ((3 0 0 0) (0 3 3 3))
The following function provides the ability to create a new
syntactic environment based on an existing environment:
AUGMENT-ENVIRONMENT env &KEY variables
specials
functions
macros
blocks
tags
types
ftypes
inlines
optimize [Function]
This function returns a new environment augmented with the
information provided by the keyword arguments. The arguments are
supplied as follows:
VARIABLES is a list of symbols, which shall be visible as
ordinary lexical variables in the new environment.
SPECIALS is a list of symbols, which shall be visible as
special declarations in the new environment.
FUNCTIONS is a list of symbols, which shall be visible as
local function bindings in the new environment.
MACROS is an a-list of symbols and macroexpansion functions.
The new environment will have local macro bindings of each symbol to
the corresponding expander function, so that MACRO-FUNCTION or
MACROEXPAND when given that symbol will use the new expander
function.
BLOCKS is a list of symbols, which shall be visible as block
names in the new environment.
TAGS is a list of symbols and integers, which shall be visible
as TAGBODY tags in the new environment.
TYPES is an a-list of symbols and type specifiers. The new
environment will have the type specifier associated with the
corresponding symbol, as if a type declaration were visible.
FTYPES is an a-list of symbols and function type specifiers.
This is analogous to TYPES, except operating in the function
namespace.
INLINES is a a-list of symbols and either the symbol INLINE or
NOTINLINE. This causes an INLINE or NOTINLINE declaration to be
visible in the new environment.
OPTIMIZE is an a-list of any of the symbols SPEED, SAFETY,
SPACE or COMPILATION-SPEED with integers between 0 and 3. These
settings will be returned by the ENVIRONMENT-OPTIMIZE-LEVEL
function for the new environment.
Rationale:
This proposal provides a portable interface to environment
information which must otherwise be obtained by
implementation-dependent means. The ENSURE-GENERIC-FUNCTION and
FIND-CLASS functions of CLOS require the ENVIRONMENT-TARGET function. A
useful code walker requires the capability of adding local function
definitions to an environment.
Cost to Implementors:
Most implementations already store this information in some form.
Providing these functions should not be too difficult, but it is a
more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides this interface currently. Portable Common
Loops defines a subset of this functionality for its code walker and
implements it on a number of diffent versions of Common Lisp.
∂02-Oct-88 1159 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 11:59:27 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 11:57:55 PDT
Date: 2 Oct 88 11:57 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
In-reply-to: Eric Benson <eb@lucid.com>'s message of Sun, 2 Oct 88 11:30:37
pdt
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
Message-ID: <881002-115755-2604@Xerox>
would you say this supercedes:
-----
Issue: SPECIAL-VARIABLE-TEST
References: Declaring Global Variables and Named Constants (pp68-69),
Declaration Specifiers (p157)
Category: ADDITION
Edit history: 07-Mar-88, Version 1 by Pitman
21-May-88, Version 2 by Pitman (correct test case, add discussion)
Status: For Internal Discussion
Problem Description:
CLtL does not define a way to test to see if a variable has been
proclaimed special (for the purposes of either binding or reference).
Programs such as macros, code-walkers, and program-generating programs
may need such information from time to time in order to do certain kinds
of reasoning about code-motion, unused variables, etc.
Proposal (SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P)
Add a function SPECIAL-VARIABLE-P by analogy with SPECIAL-FORM-P
which is defined as:
SPECIAL-VARIABLE-P symbol &optional environment [Function]
Returns T iff -symbol- names a variable which is SPECIAL in the
indicated lexical -environment-. Otherwise, it returns NIL.
It is an error if -symbol- is not a symbol. If not supplied, the
-environment- defaults to NIL, meaning the null lexical environment.
This function will be useful in determining whether a reference to
the variable named by SYMBOL in the indicated ENVIRONMENT will be
a special reference.
Note: Since special variable proclamations are pervasive and
declarations are not, the technique for determining whether binding
the variable named by SYMBOL is not dependent on the surrounding
lexical environment. It is instead dependent only on the global
environment and on the declarations of the form which would accomplish
the binding. Whether the variable has been globally proclaimed special
can be determined by doing (SPECIAL-VARIABLE-P 'symbol). Whether the
variable is locally declared SPECIAL can be checked only by parsing
the declarations looking for (DECLARE ... (SPECIAL ... symbol ...)).
Test Case:
(PROCLAIM '(SPECIAL SPECIAL-FOO))
(MACROLET ((TEST (NAME &ENVIRONMENT ENV)
`'(,NAME ,(SPECIAL-VARIABLE-P NAME ENV)) ))
(LIST* (TEST SPECIAL-FOO) ;0
(TEST FOO)
(LET ((SPECIAL-FOO 1) (FOO 1))
(LIST* (TEST SPECIAL-FOO) ;1
(TEST FOO)
(LET ((SPECIAL-FOO 2) (FOO 2))
(DECLARE (SPECIAL FOO))
(LIST* (TEST SPECIAL-FOO) ;2
(TEST FOO)
(LET ((SPECIAL-FOO 3) (FOO 3))
(LIST (TEST SPECIAL-FOO) ;3
(TEST FOO)))))))))
=> ((SPECIAL-FOO T) (FOO NIL) ;0
(SPECIAL-FOO T) (FOO NIL) ;1
(SPECIAL-FOO T) (FOO T) ;2
(SPECIAL-FOO T) (FOO NIL)) ;3
Rationale:
This would allow programs that reason about other programs to obtain
important information about SPECIAL declarations and proclamations.
Current Practice:
Interpreters and compilers must, of necessity, have a way to do this
internally.
In some implementations, information about special variable proclamations
is kept on a symbol's plist, and users eventually "figure out" how to take
advantage of that.
In most implementations, getting information about special declarations
is neither documented nor easy to "figure out".
Symbolics Genera has undocumented internal function which does this.
Cost to Implementors:
By necessity, compilers and interpreters must have a way to get the
information returned by this facility. In general, it should just be
a matter of providing a program interface to that facility.
Cost to Users:
None. This is an upward-compatible extension.
Cost of Non-Adoption:
Some code-walkers, macros, etc. would continue be hard to write in a
portable way.
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Although SPECIAL variables provide some benefit to Common Lisp, that
benefit has not been without price. It's difficult to do proper code
analysis if lexical and special variables look the same. The presence
of this operator makes it easier to write code which reasons clearly
and correctly about other programs, and so will probably tend to
improve the aesthetics of such programs.
Discussion:
This proposal came to the Cleanup committee from the Japanese community.
Pitman wrote it up formally.
Pitman and Moon support SPECIAL-VARIABLE-TEST:SPECIAL-VARIABLE-P.
∂02-Oct-88 1223 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 12:23:41 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469078; Sun 2-Oct-88 15:21:37 EDT
Date: Sun, 2 Oct 88 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
To: masinter.pa@Xerox.COM
cc: eb@lucid.com, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: <881002-115755-2604@Xerox>
Message-ID: <881002152101.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 2 Oct 88 11:57 PDT
From: masinter.pa@Xerox.COM
would you say this supercedes:
"supersedes"
Issue: SPECIAL-VARIABLE-TEST
Since EB's proposal is more elaborate and might not get past X3J13, I
would prefer if both were presented and the committee could decide.
I don't want to see the failure of this proposal to pass leave us with
nothing to show.
∂02-Oct-88 1257 CL-Compiler-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 12:57:01 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469083; Sun 2-Oct-88 15:55:26 EDT
Date: Sun, 2 Oct 88 15:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: eb@lucid.com
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810021830.AA00623@blacksox>
Message-ID: <881002155456.5.KMP@GRYPHON.SCRC.Symbolics.COM>
The return values of ENVIRONMENT-VARIABLE-KIND in this proposal clashes
with PROCLAIM-LEXICAL in a bad way. I would prefer if it returned at least
two values:
Value 1 (KIND):
NIL = No declared semantics
LEXICAL = Lexical variable
SPECIAL = Special variable
MACRO = Symbol macro
Value 2 (WHERE-DECLARED):
GLOBAL = Globally declared
LOCAL = Locally declared
NIL = Not declared
A third value you might consider returning is CONSTANT-P, so that a
variable declared by DEFCONSTANT could be distinguished. You could deal
with this by a separate function, though, similar to ENVIRONMENT-INLINE.
In fact, I also think the returned values (other than T and NIL) should
be keywords because
- keywords are easier to deal with
- keywords are safe here (the set is non-extensible)
- it would be more consistent with other inquiry functions
like FIND-SYMBOL, which return status info in keyword package.
Your suggested values would map as follows:
KMP suggestion EB suggestion
NIL, NIL NIL
SPECIAL, GLOBAL PROCLAIM
SPECIAL, LOCAL DECLARE
LEXICAL, LOCAL T
MACRO, LOCAL SYMBOL-MACROLET
My proposal leaves a few meaningless combinations, but has the virtue of
being extensible for other situations possibly yet to come, such as:
MACRO, GLOBAL Symbol macros (Symbolics Genera has them)
LEXICAL, GLOBAL Global lexicals (see issue PROCLAIM-LEXICAL)
The following other case which exists now but which you didn't address
might be worth considering, too:
NIL, GLOBAL Reserved words (eg, &FROBOZZ)
I'd also be curious to know why you want ENVIRONMENT-VARIABLE-TYPE to
return NIL in the case where something's undeclared. I propose it return
T (the default type, after all), and perhaps offer a second return value
which says whether the information was declared or defaulted. Actually,
come to think of it, the second return value could be NIL, LEXICAL, or
GLOBAL for consistency with my suggestion above.
Perhaps also ENVIRONMENT-INLINE could return as many as three values:
INLINE-P, INLINE-INFO-AVAILABLE-P, and WHERE-DECLARED
so that you could distinguish global from local information, etc.
The reason I suggest these is that a lot of kind of reasoning could
be done by looking only at the first value. The way you have all your
functions structured, you have to case for a lot more things than you
might really want to know. eg, if your only interest is to determine
if a variable is going to do a special reference, you have to look
for two markers (DECLARE and PROCLAIM) under your scheme, but a binary
value under mine. Similarly, if you want to know the type of something,
you have to special-case NIL under your scheme but can just use the
return value directly under mine. Only advanced applications where
more info is needed would need to pick up the additional values. Further,
the additional information is richer than the information provided in
your proposal.
I'll have to talk to our compiler people about the feasibility of some
of your suggestions. I may have more comments on that later.
∂02-Oct-88 1308 CL-Cleanup-mailer Re: Issue: EQUAL-STRUCTURE (Version 4)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 13:08:28 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 285058; Sun 2-Oct-88 16:05:39 EDT
Date: Sun, 2 Oct 88 16:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EQUAL-STRUCTURE (Version 4)
To: jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <4933.8810021519@subnode.aiai.ed.ac.uk>
Message-ID: <881002160549.6.KMP@GRYPHON.SCRC.Symbolics.COM>
If someone introduces an incompatible feature under the same name as an
existing feature (such as your example of instances implemented as
closures), the burden should be on them to document their way out of the
hole they have dug.
If someone introduces a compatible feature (such as Flavors support
that does not interfere with CLOS support), the documentation burden
should be only to document the extension -- not to calm their users
about imagined problems brought on by gratuitously specific wording in
the documentation.
Terms like "CLOS instances" suggest the possibility of another kind.
If we want to suggest another kind, we'll do so.
If it's any help, terms like "character string", "atomic symbol", and so
on bother me just as much...
∂02-Oct-88 1311 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 13:11:50 PDT
Received: from Burger.ms by ArpaGateway.ms ; 02 OCT 88 13:10:16 PDT
Date: 2 Oct 88 13:10 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881002-131016-2657@Xerox>
In addition to changing the issue name, I changed the Proposal wording so
that it read as a change to Common Lisp rather than a change to CLtL.
I think this is ready for release. NAK's only, please.
!
Issue: FORMAT-E-EXPONENT-SIGN
References: CLtL pp. 366, 393
Category: CLARIFICATION
Edit history: Bob Cassels, 13 Sep 88
Masinter, 2-Oct-88 (change issue name)
Related issues: <none>
Problem description:
The result of (format nil "~E" 1.0) is specified in a contradictory
way.
The ambiguity is whether a plus sign should be printed in front of
the exponent.
The top of page 393 says, "Next, either a plus or a minus sign is
printed, followed by e digits ... [decimal exponent]"
Later on page 393 we see, "If all of w, d, and e are omitted, then the
effect is ... [like prin1].
Page 366 [presumably where prin1 is defined] doesn't explicitly say
that
the plus sign is omitted from the exponent, but all the examples (and
usual practice) indicate that.
So the posssibilities are:
A. "1.0e+0"
B. "1.0e0"
The first reference implies that A is correct, the third reference
implies that B is correct. The second reference implies that A and B
are the same.
Proposal (FORMAT-E-EXPONENT-SIGN:FORCE-SIGN):
Specify that ~E always prints a plus or minus sign in front of the
exponent.
This would cause the language on page 393 of CLtL to to change:
"If all of w, d, and e are omitted, then the effect is to print the
value using ordinary free-format exponential-notation output; PRIN1
uses
a similar format for any non-zero number whose magnitude is less than
10**-3 or greater than or equal to 10**7. The only difference is that
the ~E directive always prints a plus or minus sign in front of the
exponent, while PRIN1 omits the plus sign if the exponent is
non-negative."
Test Case:
(format nil "~E" 1.0) => "1.0e+0"
Rationale:
This proposal makes ~E self-consistent. That is more important than
making ~E consistent with PRIN1.
Current practice:
Symbolics Common Lisp, Ibuki Lisp, and VAX Lisp all print the plus
sign as in the test case above. Apollo DOMAIN Common Lisp (version
2.10) and Xerox Common Lisp produce "1.0", which is wrong because
it includes no exponent at all.
Adoption Cost:
Minimal changes to one printing routine for non-conforming
implementations. (No change to the three implementations mentioned
above.)
Cost of non-adoption:
Minor confusion and possible incompatibility among implementations.
Benefits:
Less confusion, more compatibility.
Conversion Cost:
Minimal. It is doubtful that any user programs depend on this
obscure distinction.
Esthetics:
A matter of opinion.
Discussion:
Fortran ~E format requires a sign before the exponent, since the
exponent
mark character may be dropped. Since Common Lisp ~E always prints
the exponent marker, the exponent sign may be dropped in the case
that it would be a plus sign.
∂02-Oct-88 1333 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 13:33:12 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 13:31:41 PDT
Date: 2 Oct 88 13:31 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FORMAT-PRETTY-PRINT (version 5)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881002-133141-2667@Xerox>
I attempted to rewrite this as a change-to-language instead of
change-to-book, and came across some problems. I don't think that the test
case is accurate; there is no specification about the possible interaction
of *print-pretty* and *print-escape*; our pretty printer, for example,
creates significantly different output *print-escape* is NIL, and so the
two pairs are not identical except for the appearance of string quotes.
I think the intent of the proposal is to force list structures to be
printed "pretty", but we've not really defined what "pretty" is ever.
Unless that's specified, the only case over which we have control is in the
interaction with user written print functions for structures.
!
Issue: FORMAT-PRETTY-PRINT
References: FORMAT (pp. 385-388), PRIN1 (p. 83), PRINC (p. 83),
WRITE (p. 382), *PRINT-PRETTY* (p. 371)
Category: CLARIFICATION
Edit history: Version 1 by Pierson 3/4/88
Version 2 by Pierson 5/24/88 (fix name typo)
Version 3 by Pierson 6/10/88 incorporate comments
Version 4 by Pierson 6/10/88 comments from Van Roggen
Version 5 by Masinter 2-Oct-88
Problem description:
The FORMAT operators, ~A and ~S are defined to print their argument as
PRINC and PRIN1 respectively. The text does not say whether or not
these FORMAT operators must obey the *PRINT-PRETTY* flag.
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does rebind any of the printer control
variables (*PRINT-...) except as follows:
~A
Binds *PRINT-ESCAPE* to NIL.
~S
Binds *PRINT-ESCAPE* to T.
~D
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 10.
~B
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 2.
~O
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 8.
~X
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to 16.
~R
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to the value of the first argument iff a first
argument is specified.
~@C
Binds *PRINT-ESCAPE* to T.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Test Cases/Examples:
(LET ((TEST '#'(LAMBDA (X)
(LET ((*PRINT-PRETTY* T))
(PRINT X)
(FORMAT T "~%~S " X)
(TERPRI) (PRINC X) (PRINC " ")
(FORMAT T "~%~A " X)))))
(FUNCALL (EVAL TEST) TEST))
This should print four copies of the above lambda expression. The
first pair should appear identical and the second pair should appear
identical. The only difference between the two pairs should be the
absence of string quotes in the second pair.
Rationale:
FORMAT should interact with the printer control variables in a
predictable way. This proposal is one of the two simplest possible
definitions and provides the most flexibility to the user.
A major advantage of this proposal is that the following two
expressions are guaranteed to have exactly the same effect:
(FORMAT stream "~S" object)
(PRIN1 object stream)
Thus use or non-use of FORMAT becomes a purely stylistic matter.
Current practice:
Ibuki Lisp and the TI Explorer obey the binding of *PRINT-PRETTY*.
Lucid Common Lisp always applies ~A and ~S with *PRINT-PRETTY* bound
to NIL.
Cost to Implementors:
While changing FORMAT to not bind *PRINT-foo* variables is trivial,
there are some painful implications. How does a pretty-printing ~A
interact with MINCOL, etc? How much of the user interface depends on
FORMAT in ways that might be uglified by pretty printing?
Cost to Users:
Truely portable code shouldn't be affected because existing
implementations are inconsistent. Despite this, there are probably a
number of user programs in non-complying which will have to change
whichever way this is decided.
Cost of non-Adoption:
The interaction of FORMAT and the printer control variables (especially
*PRINT-PRETTY*) will remain undefined. This will continue to make
portable Common Lisp programming harder than it need be.
Benefits:
Life will be easier for users in two ways: (1) one more portability
problem will be removed, and (2) users will be more likely to be able
to persuade environmental features like debuggers to print in their
preferred way.
Aesthetics:
The interaction between two related parts of output will be clarified
in a simple way.
Discussion:
It is important to specify exactly what of Common Lisp's special
variables get rebound by other functions and macros in Common Lisp.
This cleanup issue addresses the interaction of FORMAT and the
*PRINT- variables. There may be other similar interactions in
Common Lisp that need clarification.
Otherwise, code that depends on FORMATs action in one implementation
will not port to others that do not have the same behavior.
CLtL might change as follows:
Add a header "Printer Control Variables" before the description of
*PRINT-ESCAPE* on page 370.
Add the following paragraph to page 386 just before the paragraph
starting with "It is an error":
"The FORMAT function by itself never binds any of the printer
control variables. Specific FORMAT directives bind exactly the
printer control variables specified in their description. While
implementations may specify the binding of new, implementation
specific printer control variables for each FORMAT directive, they
may neither bind any standard printer control variables not
specified in description of a FORMAT directive nor fail to bind
any standard printer control variables as specified in the
description."
∂02-Oct-88 1346 CL-Compiler-mailer Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 13:46:31 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 13:44:53 PDT
Date: 2 Oct 88 13:44 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SYNTACTIC-ENVIRONMENT-ACCESS (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sun, 2 Oct 88 15:21 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: masinter.pa@Xerox.COM, eb@lucid.com, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
Message-ID: <881002-134453-2675@Xerox>
Kent: You've always superceded me at speling.
I'm game for presenting both, if there are no squawkers here.
I'm wary of mail that goes to cl-compiler and cl-cleanup. Lets try to
decide who has an issue and pass it back if it doesn't fit.
I'm afraid we'll have more work in January that we originally expected, the
rate things are going.
∂02-Oct-88 1401 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from ELEPHANT-BUTTE.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 14:01:03 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by ELEPHANT-BUTTE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 324084; Sun 2-Oct-88 16:24:51 EDT
Date: Sun, 2 Oct 88 16:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, GLS@Think.COM
In-Reply-To: <881002-131016-2657@Xerox>
Message-ID: <881002162430.7.KMP@GRYPHON.SCRC.Symbolics.COM>
I don't care about PRIN1 and ~E being compatible, particularly, but it's
my vague recollection that some of the way ~E, ~G, and ~F are set up is
to be compatible with some Fortran programs to make translation easy. I
don't recall the details, but I even recall we talked half-seriously about
putting in Cobol picture-mode as well. I think that if this was a goal,
that we should make sure we don't accidentally violate that goal.
As long as the proposed change is not going to cause problems for people
doing translation of Fortran programs, I'm happy with the change.
I don't remember the details of this issue nor do I have a fortran
specification handy but maybe GLS or someone else reading this message
remembers the issue. Based on what other people remember about the
issue, it may be useful to mention that it was considered in the
Discussion.
∂02-Oct-88 1426 CL-Cleanup-mailer Re: Issue: FUNCTION-COERCE-TIME (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 14:26:43 PDT
Received: from Burger.ms by ArpaGateway.ms ; 02 OCT 88 14:24:50 PDT
Date: 2 Oct 88 14:24 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COERCE-TIME (Version 2)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 16 Sep 88 11:35 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881002-142450-2702@Xerox>
Well, this is a puzzle. It seems intertwined in an odd way with
FUNCTION-CALL-EVALUATION-ORDER. There we want to leave unspecified where
efunctuation takes place, but here we're trying to nail it down. There it
was important for performance. Here it isn't except where it is. Is it?
I.e., is there a performance hit for LAZY? Certainly it would force some
inlining of macros not to.
I'll go for HYBRID. Its the most implementable, and reasonable to explain,
and seems to cause the least performance hit.
Probably we need to list explicitly which functions with functional
arguments are lazy and which are ambitious.
∂02-Oct-88 1434 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 14:34:11 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 02 OCT 88 14:32:42 PDT
Date: 2 Oct 88 14:32 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 23 Jun 88 17:11 EDT
To: CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881002-143242-2709@Xerox>
At least today, I think that adding these functions would be a good idea if
we also remove the -IF-NOT functions. It would be a good idea given the
current awkwardness of preventing both a :TEST and :TEST-NOT.
Are there other things that might easily be removed?
How do you feel about removing :TEST-NOT and -IF-NOT?
∂02-Oct-88 1446 CL-Cleanup-mailer Re: Issue: FUNCTION-DEFINITION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 14:46:02 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 14:44:31 PDT
Date: 2 Oct 88 14:44 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-DEFINITION (Version 1)
In-reply-to: masinter.pa's message of 15 Sep 88 18:37 PDT
To: cl-cleanup@sail.stanford.edu
Message-ID: <881002-144431-2717@Xerox>
After re-reading this for 30 seconds, I'd favor OPTIONAL.
(Well, maybe I actually can't tell the difference between OPTIONAL and
REQUIRED, and "OPTIONAL" sounds better to me. Maybe I'm someone who votes
for a candidate because of his accent.)
I'm a little uneasy about "-DEFINITION", because in the residential
environment biz, the "definition" is the entire DEFUN form, and not just
the lambda expression.
Is there another postfix you'd also feel comfortable with? You say Many
implementations record this information, but not all that do publish an
interface to extracting the information.
This issue should reference FUNCTION-TYPE as as part of the Problem
Statement say that this is something that people used to do with just plain
old lambda expressions, since after (DEFUN FOO (X) ...) that
(SYMBOL-FUNCTION 'FOO) would frequently return the lambda expression
directly.
Now, with KCL and HP Common Lisp, the expression you get may not match what
you put in, e.g., might have gone thru some kind of preprocessing. (I
think.)
Also, how can the "definition" be a symbol? In CommonLisp?
Didn't we go thru (SETF (SYMBOL-FUNCTION X) 'FROB) before?
∂02-Oct-88 1509 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 15:09:37 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469126; Sun 2-Oct-88 18:08:25 EDT
Date: Sun, 2 Oct 88 18:07 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881002180755.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Changes...
- I thought it would be good to merge the discussion as Rationale.
- Several sections seemed to think that this proposal was making this
a "signal an error" situation. Since it was only "is an error",
implementations were still permitted to diverge. I corrected this
to make the change forbid implementations to extend the syntax.
I changed the proposal name from RESTRICT to FORBID-EXTENSION for
ease in referring to both proposals in case a problem comes up.)
- I also noticed a funny(?) ambiguity about NIL in a tagbody -- it's
both a symbol and a list. Can you GO to it? I decided to address this.
Hope the result is still non-controversial.
-----
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags
and conses as forms.
It is an error if a form in a TAGBODY is not a symbol, integer,
or NIL. Implementations are forbidden from extending this syntax.
It is an error for the same (EQL) tag to appear more than once
in the body of a TAGBODY. (However, a TAGBODY may have the
same tag as another TAGBODY in which it nests, in which case
the tag in the outer TAGBODY is shadowed, as already specified.)
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
∂02-Oct-88 1608 CL-Cleanup-mailer Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 16:07:56 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 02 OCT 88 16:06:13 PDT
Date: 2 Oct 88 16:06 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
In-reply-to: David N Gray <Gray@DSG.csc.ti.com>'s message of Thu, 15 Sep 88
14:41:36 CDT
To: David N Gray <Gray@DSG.csc.ti.com>
cc: vanroggen%aitg.DEC@decwrl.dec.com, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881002-160613-2752@Xerox>
"the proposal needs
to be extended to address this side of the issue also.
..."
Can you? Please?
∂02-Oct-88 1617 CL-Cleanup-mailer Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 2 Oct 88 16:17:30 PDT
Received: from Salvador.ms by ArpaGateway.ms ; 02 OCT 88 16:16:01 PDT
Date: 2 Oct 88 16:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4)
To: CL-CLEANUP@Sail.Stanford.EDU
cc: masinter.pa@Xerox.COM
Message-ID: <881002-161601-2756@Xerox>
This issue was apparently argued at the last two meetings. I don't think it
is very important. People are hung up in the LIST-TYPE-SPECIFIER issue, and
I think I should this should be voted on second, after we get done with
LIST-TYPE-SPECIFIER. (I'll make sure LIST-TYPE-SPECIFIER includes a forward
reference.)
!
Issue: FUNCTION-TYPE-REST-LIST-ELEMENT
References: CLtL p. 27, 47-48, 61
"Artifical Intelligence Programming", Charniak et. al.
X3J13/86-003 (A:>GLS>clarifications.text.4)
Category: CLARIFICATION, ADDITION
Edit history: Version 1, 23-Nov-1987 Sandra Loosemore
Version 2, 15-Jan-1988 Sandra Loosemore
(incorporate comments from Scott Fahlman & others)
Version 3, 13-Feb-88 Masinter
Version 4, 2-Oct-88 Masinter (update references,
discussion)
Related issues: FUNCTION-TYPE-KEY-NAME,
FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS
REST-LIST-ALLOCATION
Problem description:
The FUNCTION type specifier list is provided to allow declaration of
function argument types and return value types. This type specifier uses a
syntax similar to the usual lambda list syntax to specify which types go
with which lambda list variables. However, this is actually of limited
usefulness in the context of a declaration, where one normally wants type
information about the actual arguments which can be passed to the function
rather than the lambda variables to which they are bound.
There is a particular problem with &REST lambda variables, which are always
bound to a value of type LIST. For the sake of consistency, it would seem
that the corresponding type given in the FUNCTION declaration must also be
LIST, but since this provides no information about the actual arguments,
some users/implementors have instead adopted the convention of supplying
the type of the actual arguments which are gathered into the list.
CLtL is vague on the issue, mentioning only that &REST may appear in the
type specifier without touching upon its interpretation.
Proposal (FUNCTION-TYPE-REST-LIST-ELEMENT:USE-ACTUAL-ARGUMENT-TYPE):
Clarify that, in the FUNCTION type specifier, the type specifier provided
with &REST is the type of each actual argument, not the type of the
corresponding lambda variable.
Example:
The type of the function + would be specified as:
(FUNCTION (&REST NUMBER) NUMBER)
Rationale:
This is more useful than specifying that the type of a &REST parameter must
be LIST, since it provides information about the actual arguments.
Current practice:
There does not appear to be any concensus on this issue. Most Common Lisp
implementations currently ignore FUNCTION type declarations. The only
examples found so far are in a text book on Common Lisp, which follows the
proposed syntax.
Cost to Implementors:
Implementations that ignore the FUNCTION type specifier may continue to do
so. Probably only a small amount of code would have to be written/changed
in implementations that currently think that the &REST argument should be
LIST.
Cost to Users:
Users who have been using the convention that the &REST type parameter must
be LIST will have to change their code. However, because this issue is so
unclear, the FUNCTION type specifier is probably not used very much.
Cost of non-adoption:
If nothing is done, the FUNCTION type specifier will continue to be of
limited use for its intended purpose.
Benefits:
Adopting the proposal will clear up an area of confusion in the language
design.
Esthetics:
Debatable. One the one hand, since the argument type syntax used by the
FUNCTION type specifier mirrors normal lambda-list syntax, it would be
cleaner and less confusing to provide the type of the lambda variable
rather than the type of the actual arguments. However, considering the
types specified in the FUNCTION specifier to be the types of the actual
arguments rather than the types of the parameters as seen on the receiving
end makes the proposed semantics more palatable.
Discussion:
This issue provoked considerable debate in the cleanup committee and at
X3J13. It seems like a vote on LIST-TYPE-SPECIFIER would help clarify some
of the issues; if there is a LIST type specifier, there would be more
support for the alternative proposal to require that the &REST argument
declaration, if any, always be LIST or a subtype of LIST, and to extend the
LIST type to allow declarations of the form, e.g., (LIST NUMBER).
Those who favor USE-ACTUAL-ARGUMENT-TYPE argue that the simplicity of the
declarations and the ugliness of the alternative, as well as the weight of
current practice, argue for it.
Kent Pitman has argued against this proposal on the following grounds:
``* It is bothersome that the same argument declarations which are used
internally in the function would not be be usable externally.
``* It is unfair to provide only this special-purpose way of declaring a
sequence type when in fact there are numerous other places in the language
where it might be useful to declare a sequence type.
``If we did go with USE-ACTUAL-ARGUMENT-TYPE, it should be stated
explicitly (if it is not already in CLtL somewhere) that the following is
illegal:
(DEFUN FOO (&REST X) X)
(APPLY #'FOO T)
since there will be no way to type-declare this. Even though this is an
obscure case (that doesn't even work in some implementations), it's the
sort of thing that makes me queasy about USE-ACTUAL-ARGUMENT-TYPE.''
∂02-Oct-88 1620 CL-Cleanup-mailer Issue: LAMBDA-FORM (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 16:20:16 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469145; Sun 2-Oct-88 19:19:06 EDT
Date: Sun, 2 Oct 88 19:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LAMBDA-FORM (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881002191827.0.KMP@GRYPHON.SCRC.Symbolics.COM>
Ok, I just modified the benefits, aesthetics, and discussion to
reflect Masinter's concerns that this would make for two ways to
do the same thing. Hopefully this just makes the writeup more
fair and doesn't change anyone's vote. -kmp
-----
Issue: LAMBDA-FORM
References: LAMBDA (p59)
Category: ADDITION
Edit history: 22-Jun-88, Version 1 by Pitman
16-Sep-88, Version 2 by Pitman
02-Oct-88, Version 3 by Pitman
Status: For Internal Discussion
Problem Description:
In Scheme, one writes not #'(LAMBDA ...) but just (LAMBDA ...).
Many Common Lisp programmers have asked for this feature.
It can be written by the user, but since it's a commonly asked
for feature, it would make sense for it to be in the standard.
Also, even though the definition is trivial,
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
it is difficult to offer this as an extension because then "portable
code" tries to define it, it will get a redefinition warning because
it will be clobbering the system's predefined definition.
[An implementation could shadow LAMBDA, but that, too, has associated
problems.]
Proposal (LAMBDA-FORM:NEW-MACRO):
Add a LAMBDA macro, which has equivalent effect to:
(DEFMACRO LAMBDA (BVL &REST BODY) `#'(LAMBDA ,BVL ,@BODY))
Rationale:
This is an upward-compatible extension which ``codifies current
practice'' in that it makes a commonly defined macro available
as a standard part of the language.
Test Case:
#1: (DEFUN ADDER (N) (LAMBDA (X) (+ X N)))
(FUNCALL (ADDER 5) 3) => 8
#2: (MAPCAR (LAMBDA (X) (+ X 3)) '(1 2 3)) => (4 5 6)
#3: (MACROEXPAND '(LAMBDA (X) (+ X Y)))
=> (FUNCTION (LAMBDA (X) (+ X Y)))
Current Practice:
Symbolics Genera implements NEW-MACRO.
Symbolics Cloe does not offer a LAMBDA macro because users who defined
their own in portable code complained that they were getting redefinition
warnings that CLtL had led them to believe shouldn't happen. [Ironically,
the redefinition warnings always came when they tried to define LAMBDA
in the way it was already defined!]
Cost to Implementors:
The cost is trivial. A portable definition is shown in the
problem description above.
Cost to Users:
None. This change is basically upward compatible.
Cost of Non-Adoption:
There are no really major consequences of non-adoption.
Benefits:
It's been suggested that some people write '(LAMBDA ...) rather than
#'(LAMBDA ...) because it's less ugly, and then run into confusion
later. If they could just write (LAMBDA ...), some that use overly
superficial reasons for the choice of one notation over another might
accidentally select the primitive they should probably really be using.
Aesthetics:
Some people believe that this makes two different ways to get
essentially the same functionality, and so it clutters the language.
On the other hand, there is at least one precedent for having two
operations that do the identical thing -- NOT and NULL. Both have
been retained because they express different intents. In this case,
the intent of #'xxx might be to ``access'' a function by name (the
name of an anoymous function being its lambda expression), and the
intent of (LAMBDA ...) is to ``create'' a function. This distinction
is subtle but may be expressionally interesting to some programmers
in some situations.
Notationally, some people believe strongly that (LAMBDA ...) looks
a lot better than #'(LAMBDA ...). Certainly it takes up fewer
characters, and (LAMBDA ...) is a notable offender in code needing
to be split onto multiple lines, so every little bit probably helps.
Discussion:
Numerous people have suggested this from time to time in the past,
but it's often been amidst a bunch of other more controversial issues.
Pitman wrote up this proposal and supports LAMBDA-FORM:NEW-MACRO.
Technically, CLtL does already permit implementations to predefine a
LAMBDA macro, but most argue that this leeway was accidental. CLtL
says that "all" functions,etc in CLtL must be in the LISP package,
but it does not say "all and only". This oversight leaves enough room
for implementors to add all manner of extra junk in the LISP package.
A separate cleanup item addresses this issue.
An earlier revision of this proposal considered the alternative of
making this a new special form, but most people seemed to prefer the
simpler alternative of just making it a macro for now.
∂02-Oct-88 1836 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 18:36:49 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469167; Sun 2-Oct-88 21:35:37 EDT
Date: Sun, 2 Oct 88 21:34 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881002213452.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Date: 2 Oct 88 14:32 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
At least today, I think that adding these functions would be
a good idea if we also remove the -IF-NOT functions. It would
be a good idea given the current awkwardness of preventing
both a :TEST and :TEST-NOT.
Are there other things that might easily be removed?
How do you feel about removing :TEST-NOT and -IF-NOT?
I'm for it. Just so people have something concrete to haggle over,
here's a writeup and a separate place to discuss it.
-----
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Issue FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Current Practice:
Presumably no one has done this yet.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Discussion:
It's possible to make FLUSH-TEST-NOT or FLUSH-IF-NOT proposals
if we can't get enough people to buy into the full proposal but
think we can get consensus on a subset.
This issue is related to FUNCTION-COMPOSITION, but is not
dependent on it.
Pitman supports this change.
∂02-Oct-88 1847 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Oct 88 18:47:19 PDT
Received: from GRYPHON.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469170; Sun 2-Oct-88 21:45:52 EDT
Date: Sun, 2 Oct 88 21:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <881001212759.3.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <881002214456.5.KMP@GRYPHON.SCRC.Symbolics.COM>
[Some people didn't get copies of this when I sent it last night, so
I'm retrying. -kmp]
I tried to merge the discussion, mostly trying to use the terms "early
binding" and "tail recursion" more correctly. The changes pervade the
text.
I admit to making the changes somewhat hastily in an effort to get out
of here at a reasonable hour tonight. I hope David Gray and Eric Benson
will check carefully for any major problems since they were the ones
most vocal by the previous writeup.
[Btw, I wanted to reply to some specific comments by Gray and Masinter
with which I disagree, but I don't have time right now. I'll try to get
to them another time.]
-kmp
-----
Issue: TAIL-RECURSION-OPTIMIZATION
References: 5.1 Forms (pp54-59), SYMBOL-FUNCTION (p90)
Category: CHANGE
Edit history: 31-Aug-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman (merge discussion)
Status: For Internal Discussion
Problem Description:
Early binding of function names to function definitions is generally
inhibited in Common Lisp because CLtL says the compiler must assume
that any opaque function call might change the definition of a
function in between calls to that function.
The inability to do early binding is a barrier to doing traditional
optimizations such as tail recursion removal. For example, the best
a compiler can typically do right now when a function FOO calls
itself tail recursively is approximately:
(IF (EQ #'FOO ...what compiler expects...)
...fast jump...
...standard function calling sequence...)
Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT-EARLY-BINDING):
Permit early binding in some situations, but do not require them.
Specifically, with SPEED=0, the compiler should not do early binding
(for the sake of tracing, stack debugging, and reloading in
interactive debugging), but with in other with higher speed settings,
it is permitted to make such optimizations (except as discussed below).
Specify that the NOTINLINE declaration can be used within a function
to inhibit early binding of a function name to its definition,
regardless of the OPTMIZE SPEED setting.
Specify that the NOTINLINE proclamation can be used to globally
inhibit early binding of a function name to its definition, regardless
of the OPTMIZE SPEED setting.
Test Cases:
#1: (DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
(COND ((= X 0) N)
(T (FACTORIAL-2 (- X 1) (* N X)))))
The compiler is permitted to (but not required to) treat this
as if the following had been written instead:
(DEFUN FACTORIAL-2 (X &OPTIONAL (N 1))
(LABELS ((FACTORIAL-2 (X &OPTIONAL (N 1)))
(COND ((= X 0) N)
(T (FACTORIAL-2 (- X 1) (* N X)))))
(FACTORIAL-2 X N)))
#2: (DEFMACRO DEFUN-AUTOLOADING (NAME FILE)
`(PROGN (PROCLAIM '(NOTINLINE ,NAME))
(DEFUN ,NAME (&REST ARGUMENTS)
(LET ((OLD-ME #',NAME))
(LOAD ,FILE)
(LET ((NEW-ME #',NAME))
(WHEN (EQ OLD-ME NEW-ME)
(ERROR "Function ~S was undefined after autoload." ',NAME))
(APPLY NEW-ME ARGUMENTS))))))
(DEFUN-AUTOLOADING FOO "foo.lisp")
(DEFUN BAR (X) (FOO X))
The compiler must not make assumptions about the contents of #'FOO.
Therefore, the function BAR will always see the current definition
of FOO even in the face of runtime redefinition.
Rationale:
Early binding is an important source of speed improvement.
Program modularity is of key importance to many Common Lisp programmers,
and it would be rash to say that the compiler could simply violate
function boundaries at whim. Nevertheless, for Common Lisp to successfully
compete with other languages, it should be designed in a way that at least
permits implementations to make this optimization.
This proposal is designed to achieve a workable compromise between issues
of speed and debuggability.
Some implementations do early binding already even when it is not permitted.
Such implementations have an unfair benchmark advantage over "correct but
slow" implementations in the marketplace. This would even the odds for those
implementations who would do the optimization if only it were correct.
Current Practice:
Symbolics Genera and Symbolics Cloe not currently do early binding.
As such, they are compatible with the proposal.
Lucid Common Lisp does early binding, and so does not conform to CLtL in
some cases.
The TI Explorer assumes a function will not redefine itself and does
tail recursion removal at `higher optimization levels.'
Cost to Implementors:
None. This permits action for those interested in taking it, but does
not require any action.
Cost to Users:
Small. Some users who do runtime redefinition of functions would have to
add some declarations if they were compiling code with SPEED>0.
Cost of Non-Adoption:
Lisp would show up poorly against other languages in certain benchmarks.
Lisp vendors who do this optimization even though it's technically not
correct would continue have an unfair business advantage over vendors
over those who respect the rules of the language.
Benefits:
Compilers which chose to implement the optimization in question would
be able to produce better code.
Aesthetics:
No major aesthetic impact.
Discussion:
Pitman explored a number of different variants of this proposal before
sending this one. He's not wedded to the details here, but just tried to
submit something that would sound plausible. If there are ways to change
things which would make this proposal more palatable, he's happy to
hear them.
Charles Hornig (Symbolics) observes that SPEED=0 is perhaps not quite
the right criterion. The issue of whether absolute values of the
OPTIMIZE qualities are what's of interest or only relative values of
the different qualities is an open topic. For now, this proposal uses
SPEED 0 just to be conservative. If everyone can agree on something
broader, we could change the proposal. Alternatively, we can just
adopt that part of the proposal `as is' and work on a separate proposal
on how to deal with OPTIMIZE qualities.
David Gray has expressed reservations about this to the OPTIMIZE SPEED
quality at all since he sees it as a semantic issue.
Masinter points out that there might be some relation of this to
the issue FUNCTION-COERCE-TIME.
∂03-Oct-88 0727 CL-Cleanup-mailer Re: Issue: TEST-NOT-IF-NOT (Version 1)
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 3 Oct 88 07:27:29 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa04470; 3 Oct 88 14:35 BST
Date: Mon, 3 Oct 88 15:18:07 BST
Message-Id: <7029.8810031418@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 1)
To: Kent M Pitman <KMP@scrc-stony-brook.arpa>, CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Sun, 2 Oct 88 21:34 EDT
> This issue is related to FUNCTION-COMPOSITION, but is not
> dependent on it.
>
> Pitman supports this change.
I support this change and FUNCTION-COMPOSITION as well.
I think the reasons for could be beefed up a bit by some of the
reasons from FUNCTION-COMPOSITION (e.g., that negation of the
test is rather a special case.)
∂03-Oct-88 0958 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Oct 88 09:58:00 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA03601; Mon, 3 Oct 88 10:56:28 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA13415; Mon, 3 Oct 88 10:56:22 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810031656.AA13415@defun.utah.edu>
Date: Mon, 3 Oct 88 10:56:21 MDT
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Eric Benson <eb@lucid.com>
Cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Eric Benson <eb@lucid.com>, Sun, 2 Oct 88 11:30:37 pdt
> Date: Sun, 2 Oct 88 11:30:37 pdt
> From: Eric Benson <eb@lucid.com>
>
> ENVIRONMENT-TARGET env [Function]
>
> This function returns one of the three symbols EVAL, COMPILE or
> COMPILE-FILE, depending on whether the environment is from the
> interpreter, the in-core compiler, or the file compiler. If
> MACROEXPAND or MACROEXPAND-1 is called directly without supplying
> the environment argument, the environment passed to any expander
> functions will have target EVAL.
I really dislike this part of the proposal. I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed. The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file. I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.
As to the claim that CLOS needs this information, my understanding
from reading 88-002R is that what CLOS really needs to store in the
environment is information about the class hierarchy and which
functions are generic functions. (I'm guessing that the current
implementation does not do this, and instead stores the information
externally to the environment in different places depending on whether
it's for the compiler or interpreter.)
On the whole, I'm rather lukewarm about this proposal. I hate to add
this much more complexity to the language but I think it's probably
necessary. When local macro definitions were the only thing that the
environment was used for, you could hack out a code walker by defining
your own representation for environment objects and your own
MACROEXPAND-like function that understands that representation. I
don't think that's possible any more if we are going to start
requiring that other information (i.e., for CLOS) be stored in the
environment. Also, you really do need access to proclamations (and
not just SPECIAL proclamations).
A minor quibble: on all of the functions in this proposal that return
symbols, how about making them keywords, please?
-Sandra
-------
∂03-Oct-88 1013 CL-Cleanup-mailer Re: Issue: TEST-NOT-IF-NOT (Version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 10:13:02 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08256; Mon, 3 Oct 88 13:12:47 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA25876; Mon, 3 Oct 88 13:14:34 EDT
Message-Id: <8810031714.AA25876@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue: TEST-NOT-IF-NOT (Version 1)
In-Reply-To: Your message of 02 Oct 88 14:32:00 -0700.
<881002-143242-2709@Xerox>
Date: Mon, 03 Oct 88 13:14:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I like the combination of FUNCTION-COMPOSITION and removing :TEST-NOT
and -IF-NOT from the language but am a little worried about breaking
existing programs. Maybe this is place where we should formally
depricate a feature. This would mean that:
1. Implementations would be required to support :TEST-NOT and
-IF-NOT until the next revision of the standard.
2. The feature would appear in a special backwards compatability
section of the standard.
3. Textbooks and instructors would be encouraged not to teach
the feature.
4. Users would be warned not to use the feature for new code and
to migrate existing code away from it.
Since most existing implementations will probably feel required to do
this sort of thing anyway for the convenience of their current
customer base, maybe we should make it official.
On the other hand, if everyone else just wants to dump this feature,
I'll go along.
∂03-Oct-88 1014 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 10:14:14 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08264; Mon, 3 Oct 88 13:13:59 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA25888; Mon, 3 Oct 88 13:15:47 EDT
Message-Id: <8810031715.AA25888@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: CL-Cleanup%SAIL.STANFORD.EDU@multimax
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-Reply-To: Your message of 02 Oct 88 14:32:00 -0700.
<881002-143242-2709@Xerox>
Date: Mon, 03 Oct 88 13:15:45 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I favor FUNCTION-COMPOSITION, especially if we remove or depricate
:TEST-NOT and -IF-NOT.
∂03-Oct-88 1025 CL-Cleanup-mailer Re: Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 10:25:44 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08442; Mon, 3 Oct 88 13:25:28 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA25927; Mon, 3 Oct 88 13:27:15 EDT
Message-Id: <8810031727.AA25927@mist.UUCP>
To: masinter.pa%Xerox.COM@multimax
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: FORMAT-PRETTY-PRINT (version 5)
In-Reply-To: Your message of 02 Oct 88 13:31:00 -0700.
Date: Mon, 03 Oct 88 13:27:13 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I attempted to rewrite this as a change-to-language instead of
change-to-book, and came across some problems.
If you want, I'll try reword this but I'd rather we were able to vote
on it next week since none of your proposed changes seem substantive.
In other words, can we vote on the sentiment next week and rewrite it
for January?
I don't think that the test
case is accurate; there is no specification about the possible interaction
of *print-pretty* and *print-escape*; our pretty printer, for example,
creates significantly different output *print-escape* is NIL, and so the
two pairs are not identical except for the appearance of string quotes.
OK, I'll change the description of the test result.
I think the intent of the proposal is to force list structures to be
printed "pretty", but we've not really defined what "pretty" is ever.
Unless that's specified, the only case over which we have control is in the
interaction with user written print functions for structures.
Neither CLtL nor this proposal try to define what "pretty" list
structures are, but both assume that many implementations will do
something different and both provide access to that unspecified
difference. I think that both the vagueness and the access are useful
in most implementations.
∂03-Oct-88 1035 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 10:35:14 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08641; Mon, 3 Oct 88 13:34:50 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA25962; Mon, 3 Oct 88 13:36:36 EDT
Message-Id: <8810031736.AA25962@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of Thu, 22 Sep 88 12:30:00 -0400.
Date: Mon, 03 Oct 88 13:36:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I haven't figured out whether what he
really wants is to be allowed to redefine the unnamed function that
WRITE, PRINT, PRINC, FORMAT, etc. all call, or whether he wants to be
able to redefine the unnamed function that the read-eval-print loop
calls to print things.
I want to be able to redefine all of the above, in particular I want
to be able to force all interaction, including REP loops, debugger,
tracer, etc. to use my pretty print function. Of course it will
always be possible for a sufficiently dedicated implementation or
application to defeat this either by rebinding *PRINT-PRETTY* or by
using internal print functions which don't follow the normal rules,
but there will be much less chance of an implementation or application
unintentionally preventing me from specifying my own pretty printer.
Also of course, if I do this I take the risk that my pretty printer
will interact unfavorably with the implementation in other ways, but
as one vendor likes to say: "Here's the gun, there's my foot".
Using the value of *PRINT-PRETTY* to enable a user-defined pretty
printer is incompatible with Symbolics' current practice, where the
value of *PRINT-PRETTY* tells the pretty printer additional
information about the value being printed, for instance whether it is
a program or data. This should be orthogonal to the choice of which
pretty printer to use. This pretty printer was written by Dick
Waters, so perhaps his current portable pretty printer uses the same
technique.
Well, if the *PRINT-PRETTY* value hack won't work I'm open to
suggestions. One possibility is to add a new variable, say
*PRINT-PRETTY-FUNCTION*. Another, which will cause screams of
outrage, is to fbind *PRINT-PRETTY* as well as bind it. User
redefinition of PPRINT is probably not a good choice.
∂03-Oct-88 1038 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 10:37:52 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA08683; Mon, 3 Oct 88 13:37:36 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA25971; Mon, 3 Oct 88 13:39:23 EDT
Message-Id: <8810031739.AA25971@mist.UUCP>
To: Patrick Dussud <dussud%lucid.com@multimax>
Cc: cl-cleanup%sail.stanford.edu@Multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of Fri, 23 Sep 88 08:44:24 -0700.
<8809231544.AA24733@rainbow-warrior>
Date: Mon, 03 Oct 88 13:39:21 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Would it help if the pretty print function took an additional optional
argument, the current print level (the current print length always
starts at 0 when the function is called.)
I think it makes it more consistent with the structure print
functions. I don't think that you can win all the time, because,
if your print function calls a Common Lisp print function (print,
princ...), then you lose the depth.
Not really because I would expect my pretty print function to only
call a Common Lisp print function on known leaves.
∂03-Oct-88 1309 CL-Cleanup-mailer Deprication, cleanup goals, performance
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 3 Oct 88 13:08:54 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA12267; Mon, 3 Oct 88 16:08:08 EDT
Received: from Burger.ms by ArpaGateway.ms ; 03 OCT 88 12:29:39 PDT
Date: 3 Oct 88 12:03 PDT
From: masinter.pa@Xerox.COM
Subject: Deprication, cleanup goals, performance
In-Reply-To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>'s message of
Mon, 03 Oct 88 13:14:32 EDT
To: Dan L. Pierson <pierson%mist@MULTIMAX.ENCORE.COM>
Cc: masinter.pa%Xerox.COM@MULTIMAX.ENCORE.COM,
cl-cleanup%sail.stanford.edu@MULTIMAX.ENCORE.COM
Message-Id: <881003-122939-1139@Xerox>
I'd like to separate the strategy for dealing with the incompatible changes
from the changes themselves. We have made other minor and major
incompatible changes to Common Lisp and will probably make more before
we're done. We need a general way of dealing with features that are omitted
and incompatible changes, and the steps you've outlined are reasonable.
Maybe I've said this before, but I think as far as cleanup is concerned
our major question is: does this make the language enough "better" to be
worth the cost. "Better" is not evaluated in isolation: while "cleaner" and
"easier to understand" are good properties of a programming language, a
language is also "better" if there already exist a lot of programs written
in it, if there already exist textbooks that teach it.
If we make too many changes to the point where old programs can no longer
be made to work or if the old textbooks no longer apply.
Each of us may have different way of combining these orthogonal goals of
"better": folks differ on the importance of compatibility with existing
programs, on the value of simplicity over power and expressiveness.
In the specific case of TEST-NOT-IF-NOT, I think that it makes the language
enough better along the dimensions of cleanliness, and has little impact on
backward compatibility.
One aspect of "better" that seems to be of concern to the community yet we
don't address in the cleanup "issue form" is the impact on performance.
Does this make the language more or less easy to implement efficiently. I'm
thinking about adding a "Performance Impact" to the cleanup form, since it
seems to be an undercurrent in a lot of the discussions.
What do you think?
∂03-Oct-88 1323 CL-Cleanup-mailer Deprecation, cleanup goals, performance
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 13:22:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469639; Mon 3-Oct-88 16:21:10 EDT
Date: Mon, 3 Oct 88 16:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Deprecation, cleanup goals, performance
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU, pierson%mist@Multimax.Encore.COM
In-Reply-To: <881003-122939-1139@Xerox>
Message-ID: <881003162151.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
I agree with Masinter's comments about separating the goal and the
mechanism.
When it does come to talking about mechanisms, though, it's wise to
keep in mind that unlike probably all other languages which provide these
deprecated features, Lisp has meta-level primitives capable of "noticing"
the changes in a way that affects programs. By this I mean that since names
in the language are first class structures (ie, symbols), deprecation comes
at no small cost. I don't think it's wise for us to think of phasing out a
symbol on the Lisp package partly because removing it will lead to all
kinds of confusion with packages using other packages that may or may not
have the symbol (depending on the implementation), problems with print/read
of symbols across systems, etc.
∂03-Oct-88 1538 CL-Cleanup-mailer Re: Issue: NTH-VALUE (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 15:38:22 PDT
Received: by ti.com id AA25611; Mon, 3 Oct 88 17:34:36 CDT
Received: from Kelvin by tilde id AA12180; Mon, 3 Oct 88 17:25:49 CDT
Message-Id: <2800909595-11375570@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 3 Oct 88 17:26:35 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: NTH-VALUE (Version 2)
In-Reply-To: Msg of Sat, 1 Oct 88 20:46 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
> Proposal (NTH-VALUE:ADD):
>
> Add a new macro NTH-VALUE, described as
>
> NTH-VALUE n form [Macro]
>
> Evaluates the FORM and returns the Nth value returned by the form as
> a single value. N is 0-based, i.e. the first returned value is
> value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
> evaluated, in left-to-right order.
...
> Current practice:
>
> No implementation is known to provide this feature.
The TI Explorer and LMI Lambda have this.
[This is not necessarily an endorsement, however, since it seems to be
only rarely used.]
∂03-Oct-88 1539 CL-Cleanup-mailer Re: Issue: KILL-PACKAGE (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 15:38:53 PDT
Received: by ti.com id AA25603; Mon, 3 Oct 88 17:34:26 CDT
Received: from Kelvin by tilde id AA11917; Mon, 3 Oct 88 17:16:38 CDT
Message-Id: <2800909048-11342747@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 3 Oct 88 17:17:28 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: KILL-PACKAGE (Version 2)
In-Reply-To: Msg of Sat, 1 Oct 88 16:55 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
> Proposal (KILL-PACKAGE:NEW-FUNCTION):
>
> Introduce the function DELETE-PACKAGE, described as follows:
...
> Current Practice:
The Explorer has both a DELETE-PACKAGE and a KILL-PACKAGE function.
KILL-PACKAGE appears to conform to this proposal except that it returns
NIL instead of T. DELETE-PACKAGE differs by signaling an error when the
package is used by another package, and by uninterning all of the
symbols.
∂03-Oct-88 1720 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 3 Oct 88 17:20:45 PDT
Received: by ti.com id AA26248; Mon, 3 Oct 88 19:18:51 CDT
Received: from Kelvin by tilde id AA14043; Mon, 3 Oct 88 19:09:12 CDT
Message-Id: <2800915811-11749067@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 3 Oct 88 19:10:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
Cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
In-Reply-To: Msg of Sun, 2 Oct 88 21:44 EDT from Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>
> Early binding of function names to function definitions is generally
> inhibited in Common Lisp because CLtL says the compiler must assume
> that any opaque function call might change the definition of a
> function in between calls to that function.
Is there a specific place in CLtL that clearly says that, or is it
just inferred from the ability to SETF SYMBOL-FUNCTION without
restrictions on where or when?
> Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT-EARLY-BINDING):
>
> Permit early binding in some situations, but do not require them.
This doesn't define what "early binding" means. The test cases suggest
what the intent is, but I'm not comfortable with specification by
example. In particular, it isn't clear whether you intend to affect the
case of one function calling another, or if you are only talking about
functions that reference their own definition.
> Specifically, with SPEED=0, the compiler should not do early binding
> (for the sake of tracing, stack debugging, and reloading in
> interactive debugging), ...
Given that intent, if proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY is
adopted, then a more appropriate criteria might be DEBUG>SPEED.
Actually, though, if debugability is the issue, this might be beyond
what the standard ought to specify, since nowhere else does it specify
what happens at particular optimization levels.
> ... but with in other with higher speed settings, ...
The grammar didn't come out right on that.
> regardless of the OPTMIZE SPEED setting.
OPTIMIZE
> of the OPTMIZE SPEED setting.
ditto
> Current Practice:
>
> Symbolics Genera and Symbolics Cloe not currently do early binding.
"not" -> "do not"
> David Gray has expressed reservations about this to the OPTIMIZE SPEED
> quality at all since he sees it as a semantic issue.
... about tying this to the OPTIMIZE qualities ...
Actually, I thought _you_ were presenting it as a semantic issue.
∂03-Oct-88 1854 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 18:54:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469957; Mon 3-Oct-88 21:52:56 EDT
Date: Mon, 3 Oct 88 21:52 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810031736.AA25962@mist.UUCP>
Message-ID: <19881004015229.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't think you answered my question. Do you want to change the
effect of -all- calls to WRITE, PRINT, FORMAT ~S, etc.? Or do you
want to only change the printing by interactive tools (you mentioned
the read-eval-print loop, the debugger, and trace)?
It sounds to me like what you want is a function you can redefine
(or equivalently a variable you can SETQ to a function) together
with a specification of in what situations the function will be
called. Once that's clear a name can be chosen. Possibly the
feature already exists in the language, via a :AROUND method
on PRINT-OBJECT with no specialized parameters, depending on whether
what that does is precisely what you wanted.
∂03-Oct-88 1932 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 19:32:49 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469972; Mon 3-Oct-88 22:31:27 EDT
Date: Mon, 3 Oct 88 22:30 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 1)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881002213452.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004023059.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I don't buy the argument that this makes the language smaller, since
I don't think -IF-NOT and :TEST-NOT make the language larger to any
significant extent either in terms of difficulty of teaching or
difficulty of implementation; that's because these features are just
minor variations of other features that you are not proposing to remove.
It's not true that it's not clear what to do when both :TEST and :TEST-NOT
are specified; CLtL p.245 (near the bottom of the page) is quite explicit
that this is an error. Nevertheless, the need for this restriction is
unaesthetic, and that consideration changed my opposition to this
proposal from vehement to mild. The only reason I'm opposed now is
that I'm opposed on principle to incompatible changes in mature languages.
∂03-Oct-88 1954 CL-Compiler-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 19:54:50 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469980; Mon 3-Oct-88 22:52:07 EDT
Date: Mon, 3 Oct 88 22:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810031656.AA13415@defun.utah.edu>
Message-ID: <19881004025148.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
> ENVIRONMENT-TARGET env [Function]
>
> This function returns one of the three symbols EVAL, COMPILE or
> COMPILE-FILE, depending on whether the environment is from the
> interpreter, the in-core compiler, or the file compiler. If
> MACROEXPAND or MACROEXPAND-1 is called directly without supplying
> the environment argument, the environment passed to any expander
> functions will have target EVAL.
I really dislike this part of the proposal. I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed. The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file. I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.
I think we have some confusion here between interpreter versus compiler
on the one hand, and operating in the local Lisp world versus outputting
to a file to be loaded later on the other hand. I feel that it is
completely inappropriate to add something that distinguishes between
the compiler and the interpreter. I'd like to see that part of the
proposal dropped.
The important distinction is between what I will call local environments
and remote environments. A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
evaluated in a local environment affects the current Lisp world, but in
a remote environment it does not affect the current Lisp world, however
its effects still need to be remembered in a model of the Lisp world
that will be created later. Both COMPILE-FILE and your example program
annotating program work with remote environments. I defy you to come up
with an example where the local/remote environment distinction doesn't
make sense and a third type is needed. Thus I think ENVIRONMENT-TARGET
would better be named ENVIRONMENT-REMOTE-P.
As to the claim that CLOS needs this information, my understanding
from reading 88-002R is that what CLOS really needs to store in the
environment is information about the class hierarchy and which
functions are generic functions. (I'm guessing that the current
implementation does not do this, and instead stores the information
externally to the environment in different places depending on whether
it's for the compiler or interpreter.)
Does (setf (gethash a ht) b) mean that b is a part of a?
Again the compiler/interpreter distinction is a red herring and CLOS has
no reason to care about that distinction. The important distinction
is local/remote. CLOS needs to know whether a DEFCLASS form changes the
behavior of objects of that class in the current world, or only affects
a future ("remote") world. Whether this information is "inside" the
environment or "associated with" the environment is a red herring too,
I think; it's a matter of implementation, but has no effect on the
functional interface that the user sees. I think it's better only to
standardize the one thing that has to be standardized, the local/remote
distinction, and leave the rest (the actual name<->object mapping) to
the discretion of individual implementations. That way we'll get this
business over with quicker.
∂03-Oct-88 1959 CL-Compiler-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 19:58:45 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469981; Mon 3-Oct-88 22:57:10 EDT
Date: Mon, 3 Oct 88 22:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, eb@lucid.com
cc: cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <881002155456.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004025653.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with the general tenor of Kent's comments. I'd like to see
an alternate version of the proposal written up that way, so we can
see the ramifications.
I also wonder about having separate accessors for scope, type, and
(for functions) inlinitude. Would it be more or less elegant to
have a single accessor that returns all this information as multiple
values? I'd say more elegant, although I'm not sure what happens
if the type was proclaimed but the inlinitude was declared.
∂03-Oct-88 2042 CL-Cleanup-mailer Issue: EQUAL-STRUCTURE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 20:42:03 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 469997; Mon 3-Oct-88 23:40:33 EDT
Date: Mon, 3 Oct 88 23:40 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EQUAL-STRUCTURE (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Masinter.PA@Xerox.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881001184620.6.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004034015.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Sat, 1 Oct 88 18:46 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Can we not say "CLOS instances" and just use "instances"? The single
word is not ambiguous now that CLOS is adopted. I don't want users of a
Flavors compatibility package to get worried that "CLOS instances" and
"Flavors instances" might be different. I'd rather the paragraph on
EQUALP read:
EQUALP is similar, except that it ignores case in strings,
descends arrays, structures, and instances. It uses EQ for
all other types; for example, it does not descend hash tables.
The problem with this is that there is no such concept as "an instance"
in CLOS. The word "instance" is only used in the phrase "an instance
of a class". Every, every object is an instance of some class. In
CLOS terms, where you said "instances" I think you meant "members
of STANDARD-OBJECT" or "instances of STANDARD-OBJECT or of a subclass
of that class" (the latter two phrases are synonymous). Also of course
as I think JonL pointed out what this says is not what EQUALP does,
at least remember that it uses = for numbers.
∂03-Oct-88 2049 CL-Cleanup-mailer Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 3 Oct 88 20:49:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470003; Mon 3-Oct-88 23:47:34 EDT
Date: Mon, 3 Oct 88 23:47 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-FUNCTION-AMBIGUITY (version 3)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <880930-174820-1519@Xerox>
Message-ID: <19881004034715.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I don't have strong feelings, since I would never use FTYPE or FUNCTION
declarations anyway. Nonetheless, I have to oppose this proposal because
it is a completely unnecessary incompatible change to the language. It
removes the traditional FUNCTION declaration on the grounds that it is
unesthetic to distinguish the old and new FUNCTION declarations on the
basis of whether something is a symbol or a list; this does not strike
me as sufficient justification for an incompatible change.
My opposition is not strong, but I do feel that the proponents of this
proposal should reconsider what they are doing.
∂03-Oct-88 2102 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 3 Oct 88 21:02:20 PDT
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23101; Mon, 3 Oct 88 22:00:33 MDT
Received: by defun.utah.edu (5.54/utah-2.0-leaf)
id AA13928; Mon, 3 Oct 88 22:00:25 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8810040400.AA13928@defun.utah.edu>
Date: Mon, 3 Oct 88 22:00:24 MDT
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Cc: Eric Benson <eb@lucid.com>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 3 Oct 88 22:51 EDT
> Date: Mon, 3 Oct 88 22:51 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> The important distinction is between what I will call local environments
> and remote environments. A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
> evaluated in a local environment affects the current Lisp world, but in
> a remote environment it does not affect the current Lisp world, however
> its effects still need to be remembered in a model of the Lisp world
> that will be created later. Both COMPILE-FILE and your example program
> annotating program work with remote environments. I defy you to come up
> with an example where the local/remote environment distinction doesn't
> make sense and a third type is needed. Thus I think ENVIRONMENT-TARGET
> would better be named ENVIRONMENT-REMOTE-P.
That's a very nice way to put it. Rather than trying to introduce
*more* kinds of environments, I would actually go in the other
direction and say that code walkers shouldn't even need to know the
distinction between local and remote environments. An implementation
ought to be free to use different representations for the two, but as
long as the accessors return the correct information, is there any
reason why you would need to know where it came from?
> Again the compiler/interpreter distinction is a red herring and CLOS has
> no reason to care about that distinction. The important distinction
> is local/remote. CLOS needs to know whether a DEFCLASS form changes the
> behavior of objects of that class in the current world, or only affects
> a future ("remote") world.
That's pretty much what I was trying to say: CLOS doesn't really need
to know whether the information is needed by the compiler or
interpreter or something else, as long as it finds the right
information.
If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment. The existing proposal assumes that everything the
compiler doesn't create must be an EVAL (that is, local) environment.
One other thing I would like clarified. It makes sense to be able to
have more than one distinct remote environment around at any given
time; for example, if COMPILE-FILE is called recursively it ought to
create a new remote environment for each file. Does it make any sense
to have more than one distinct local environment around, or is there
only one? I can imagine that a Lisp running on a non-shared-memory
parallel machine might want to maintain separate local environments on
each processor, for instance. Would doing so automatically make that
Lisp not be Common Lisp?
-Sandra
-------
∂04-Oct-88 0911 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 4 Oct 88 09:11:12 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA00274; Tue, 4 Oct 88 11:03:47 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA26956; Tue, 4 Oct 88 09:57:36 EDT
Message-Id: <8810041357.AA26956@mist.UUCP>
To: "David A. Moon" <Moon%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
In-Reply-To: Your message of Mon, 03 Oct 88 21:52:00 -0400.
<19881004015229.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 04 Oct 88 09:57:34 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I don't think you answered my question. Do you want to change the
effect of -all- calls to WRITE, PRINT, FORMAT ~S, etc.? Or do you
want to only change the printing by interactive tools (you mentioned
the read-eval-print loop, the debugger, and trace)?
Sorry, I want to change the effect of -all- calls. The only reason
that I harp on the interactive tools is that they are frequently the
hardest to change. If my own code wants to avoid the this feature I
can easily disable it locally.
It sounds to me like what you want is a function you can redefine
(or equivalently a variable you can SETQ to a function) together
with a specification of in what situations the function will be
called.
Right, though dynamic binding would be more convenient than setting in
some cases such as local disabling.
Once that's clear a name can be chosen. Possibly the
feature already exists in the language, via a :AROUND method
on PRINT-OBJECT with no specialized parameters, depending on whether
what that does is precisely what you wanted.
Does it do what I want (I'm not yet a CLOS theologian)?
∂04-Oct-88 1223 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 12:16:55 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470363; Tue 4-Oct-88 15:15:27 EDT
Date: Tue, 4 Oct 88 15:14 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPT-RATIO (Version 1)
To: CL-Cleanup@sail.stanford.edu
cc: JGA@STONY-BROOK.SCRC.Symbolics.COM, Cassels@STONY-BROOK.SCRC.Symbolics.COM
References: <19880930174110.6.JGA@JUBJUB.SCRC.Symbolics.COM>
Message-ID: <19881004191447.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Issue: EXPT-RATIO
References: CLtL pages 204 and 211
Category: CLARIFICATION
Edit history: Version 1, 4-Oct-88, by Aspinall and Moon
Problem description:
The comment (page 204, 2nd para) that "... an implementation [of expt]
might choose to compute (expt x 3/2) as if it had been written
(sqrt (expt x 3) 2)" disagrees with the principal value definition on
page 211. See the example below for a case where the two disagree. We
believe the principal value definitions are consistent and reasonable,
therefore the implementation comment is wrong.
Proposal (EXPT-RATIO:211):
Clarify that (sqrt (expt x 3) 2) is not equivalent to (expt x 3/2)
and that page 211 rules.
Test Cases/Examples:
(defvar x (exp (/ (* 2 pi #c(0 1)) 3))) ;exp(2.pi.i/3)
(expt x 3) => 1 (except for round-off error)
(sqrt (expt x 3)) => 1 (except for round-off error)
(expt x 3/2) => -1 (except for round-off error)
There can be no question that
(expt x 3) ==> 1
because expt is single-valued with an integer second argument, and
(sqrt 1) ==> 1
definitely follows the principal branch of the square root function.
But (expt x 3/2) is defined as (exp (* (log x) 3/2)) (page 211).
(log x) ==> 2.pi.i/3
according to the definition of the logarithm's branch cuts on page 211
(which really comes down to the branch cuts of phase - page 210), so
(* (log x) 3/2) ==> pi.i
and
exp(pi.i) is -1.
Rationale:
We believe the principal value definitions are consistent and
reasonable, therefore the implementation comment is wrong.
Current practice:
Symbolics Genera 7.3 currently returns the wrong answer, following page
204 rather than page 211. We have not surveyed any other implementations.
Cost to Implementors:
The obvious code changes in complex expt.
Cost to Users:
None.
Cost of non-adoption:
Self-contradictory language specification.
Benefits:
Users can better predict the branch cuts in expt.
Discussion:
Mathematical Explanation: When the expt function returns a complex result
in CL (Cartesian) form, the phase of the complex number is effectively
canonicalized. Information is lost, and that information is necessary to
specify upon which branch of the sqrt function the final result should lie.
Another way to put it would be that although
sqrt(expt(x,3)) = expt(x,3/2)
where expt and sqrt are the mathematical multi-valued functions, it is not
true that:
pv-sqrt(pv-expt(x,3)) = pv-expt(x,3/2)
where pv-expt and pv-sqrt denote the principal value versions of those functions.
∂04-Oct-88 1303 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 13:03:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470397; Tue 4-Oct-88 16:01:48 EDT
Date: Tue, 4 Oct 88 16:01 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXPT-RATIO (Version 1)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@sail.stanford.edu, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Cassels@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <19881004191447.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881004160138.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
A small non-technical comment:
If there's a next draft, you might want to change "pv-sqrt" and
"pv-expt" in the Discussion to names that don't use hyphens, like
"pvsqrt" or "pv_sqrt". Hyphen looks like a minus-sign when using
infix notation.
∂04-Oct-88 1410 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 14:04:34 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470456; Tue 4-Oct-88 17:03:08 EDT
Date: Tue, 4 Oct 88 17:02 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881002180755.9.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004210239.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I approve TAGBODY-CONTENTS:FORBID-EXTENSION, except that
you need to change the sentence
It is an error if a form in a TAGBODY is not a symbol, integer,
or NIL.
to say whatever you really meant. You probably meant to include
tags as well as forms and you probably did not mean to exclude
conses as valid forms.
∂04-Oct-88 1419 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 14:18:58 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470470; Tue 4-Oct-88 17:17:31 EDT
Date: Tue, 4 Oct 88 17:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881001165530.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004211714.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
KILL-PACKAGE:NEW-FUNCTION is fine with me, either as proposed
or with JonL's suggested modifications.
∂04-Oct-88 1420 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 14:20:39 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470472; Tue 4-Oct-88 17:19:18 EDT
Date: Tue, 4 Oct 88 17:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881004171910.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, I changed the first two paragraphs of the proposal slightly
to accomodate criticisms by Moon and Gray. Everything else is
the same.
Hopefully ready for release...
-----
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags,
and treats conses as forms.
It is an error if an expression in a TAGBODY is not a symbol,
an integer, or a cons. Implementations are forbidden from
extending this syntax.
It is an error for the same (EQL) tag to appear more than once
in the body of a TAGBODY. (However, a TAGBODY may have the
same tag as another TAGBODY in which it nests, in which case
the tag in the outer TAGBODY is shadowed, as already specified.)
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
∂04-Oct-88 1431 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 14:31:42 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470483; Tue 4-Oct-88 17:30:13 EDT
Date: Tue, 4 Oct 88 17:29 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 2)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880927130442.2.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881004212955.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 27 Sep 88 13:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
How would you feel about something like the following. It's
broader, but still tries to be specific...
Symbols on the LISP package may have function or macro
definitions, variable definitions or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
Neither users nor implementors are permitted to add new kinds of
definitions for these symbols.
I agree with those who have commented that it is not Common Lisp
(the language)'s business to prohibit users from doing this. It
would make sense to advise users that it's a dangerous practice.
I like the analogy with the advise to users to enclose names of
special variables in asterisks.
As for the system, I agree with what I think is your intent, but
the wording would need to be much more unambiguous for this to be
viable in a language specification. I was going to try to help
with the wording, but decided I didn't have time.
∂04-Oct-88 1434 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Oct 88 14:34:05 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Tue, 4 Oct 88 16:54:02 EDT
Received: by joplin.think.com; Tue, 4 Oct 88 17:30:01 EDT
Date: Tue, 4 Oct 88 17:30:01 EDT
From: gls@Think.COM
Message-Id: <8810042130.AA25019@joplin.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: masinter.pa@xerox.com, cl-cleanup@sail.stanford.edu, GLS@Think.COM
In-Reply-To: Kent M Pitman's message of Sun, 2 Oct 88 16:24 EDT <881002162430.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Date: Sun, 2 Oct 88 16:24 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
I don't care about PRIN1 and ~E being compatible, particularly, but it's
my vague recollection that some of the way ~E, ~G, and ~F are set up is
to be compatible with some Fortran programs to make translation easy. I
don't recall the details, but I even recall we talked half-seriously about
putting in Cobol picture-mode as well. I think that if this was a goal,
that we should make sure we don't accidentally violate that goal.
As long as the proposed change is not going to cause problems for people
doing translation of Fortran programs, I'm happy with the change.
I don't remember the details of this issue nor do I have a fortran
specification handy but maybe GLS or someone else reading this message
remembers the issue. Based on what other people remember about the
issue, it may be useful to mention that it was considered in the
Discussion.
It doesn't much matter to Fortran what ~E does when w and d are missing
because Fortran does not allow them to be omitted. I agree that this
point should be tied down, but have no string opinion over which way
it should go.
--Guy
∂04-Oct-88 1508 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 15:07:01 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470509; Tue 4-Oct-88 18:05:06 EDT
Date: Tue, 4 Oct 88 18:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 3)
To: JonL@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881004180459.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Well, no one else had much to say and I had more time to think about
this, so I decided to try to merge your suggestions and mine. I think
I've satisfied both our stated goals -- let me know if I have not.
I changed a bunch of the details of the Proposal section to make it
signal more errors, and to specify the corrective action that happens
if you continue.
The changed sections are: Proposal, Test Case, and Current Practice.
Procyon and Lucid Lisp guys especially should check the Current Practice.
-----
Issue: KILL-PACKAGE
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
04-Oct-88, Version 3 by Pitman
(provide for correctable errors in some cases)
Status: For Internal Discussion
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (KILL-PACKAGE:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package as it would have if no conflict had
occurred.
The principal effect of deleting the package is that the name and
nicknames of the designated package cease to be recognized package
names.
Any symbols in the designated package still exist after this function
is called. If their home package was not the package to be deleted, the
home package will be unchanged. If their home package was that package,
the home package after this operation is unspecified; the effect of
printing such symbols is also unspecified.
The designated package persists after this function is called.
PACKAGEP is still true of it, but PACKAGE-NAME will return NIL.
The effect of any other package operation on PACKAGE once it has been
deleted is undefined.
DELETE-PACKAGE returns T (if the deletion attempt was successful).
Test Case:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
Error: Package BAZ uses package BAR.
If continued, BAZ will be made to unuse-package BAR,
and then BAR will be deleted.
Type :CONTINUE to continue.
Debug> :CONTINUE
=> T
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior
except that an error is not signalled if the package is used.
When a package is killed by PKG-KILL, the home package of all symbols
in that package are left undisturbed (i.e., local symbols pointing to
the killed package); this aspect is compatible with the stated proposal.
Procyon Common Lisp has a DELETE-PACKAGE already. It returns the name
of the package so deleted (as a string). [Perhaps it also differs in the
correctability of the errors it signals? -kmp]
Lucid Common Lisp provides DELETE-PACKAGE but the argument must be a
package object.
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Pitman supports this addition.
∂04-Oct-88 1548 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 15:48:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470547; Tue 4-Oct-88 18:46:46 EDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 470537; Tue 4-Oct-88 18:32:25 EDT
Date: Tue, 4 Oct 88 18:32 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 3)
To: peck@Sun.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8810042215.AA11605@denali.sun.com>
Message-ID: <881004183219.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 4 Oct 88 18:46 EDT
Resent-Message-ID: <881004184640.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
That's an interesting issue that at least I was not thinking of.
Since the current situation is technically ambiguous, I would
argue that the code you're citing was technically in error.
But by the same argument, so is the (GO NIL) case I was citing.
Since my guess is that there are many more cases of the situation
you describe than there are of (GO NIL), my inclination would be
to invert things.
Since I have to rewrite the proposal anyway to merge your useful
comments, I could just as well change it to make NIL a form and
not a tag.
If anyone has an opinion on this, they should speak now.
∂04-Oct-88 1557 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 4 Oct 88 15:57:27 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by Riverside.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 285552; Tue 4-Oct-88 18:55:19 EDT
Return-path: <peck@SUN.COM>
Received: from SUN.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 470521; 4 Oct 88 18:13:58 EDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA02991; Tue, 4 Oct 88 15:11:07 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA19126; Tue, 4 Oct 88 15:14:03 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA11605; Tue, 4 Oct 88 15:15:51 PDT
Message-Id: <8810042215.AA11605@denali.sun.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 3)
In-Reply-To: Your message of Tue, 04 Oct 88 17:19:00 -0400;
<881004171910.6.KMP@BOBOLINK.SCRC.Symbolics.COM> .
Date: Tue, 04 Oct 88 15:15:49 -0700
From: peck@Sun.COM
Resent-To: CL-Cleanup@SAIL.Stanford.EDU
Resent-From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Resent-Date: Tue, 4 Oct 88 18:55 EDT
Resent-Message-ID: <881004185556.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Is anybody concerned about macros that expand to a tagbody with NIL forms?
If NIL is a statement in a tagbody then they disappear quietly,
especially after a pass by a good compiler.
With the current proposal, though, one will get:
"ERROR: Multiple appearances of tag NIL."
I don't know what current practice is, if code like this has
always signalled an error then this is a total non-issue.
If not, it might be noted as a possible conversion cost.
Code like FOO1 will need to be rewritten to splice like in FOO2.
[sometimes it may not be this easy...]
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
(defmacro foo2 (&rest args)
`(do () ((test-fn))
,@(when (member :bar args) '((do-bar-thing)))
,@(when (member :baz args) '((do-baz-things)))
(do-regular-things)))
∂05-Oct-88 0059 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 00:59:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 00:57:24 PDT
Date: 5 Oct 88 00:57 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
To: cl-cleanup@sail.stanford.edu
Message-ID: <881005-005724-4531@Xerox>
I realized that this only went to a couple of individuals rather than the
whole list. As I would like it Ready for Release by last week, and Benson
asked for the latest version, I'm mailing this one out.
In general, if you're having private discussions on an issue, please keep
me informed so I know what's happening. I'd just as soon you cc'd
cl-cleanup on issues. Please don't cc common-lisp and/or cl-editorial on
the same message unless it is absolutely necessary.
!
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
Problem description:
CLtL occasionally draws a distinction between type-specifiers
"for declaration" and "for discrimination". Many people are confused
by this situation, which may be one of the more insidious flaws in the
current CL design. A consequence of this "flaw" is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have *none* of its
values ever satisfy the typep predicate with that type-specifier.
One type-specifier with this property is
<certain-type> = (ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example,
in most implementations of CL, an array X created with and element-type
of (SIGNED-BYTE 5) will, depending on the vendor, either satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
This proposal suggests elimination of this distinction for the array types
ARRAY, SIMPLE-ARRAY, and VECTOR and their subtypes, by guaranteeing that
arrays constructed with a specific element-type satisfy the typep predicate
with the derived array type-specifier, and by guaranteeing that subtypep
reflect the type equivalences defined by the behavior of make-array.
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
-- Introduce a function, UPGRADE-ARRAY-ELEMENT-TYPE of one argument, which
reveals how the given implementation treats a particular :element-type
argument to make-array. Given a type-specifier <type1> as argument, it
returns a maximal type-specifier <type2> such that <type2> is the
actual specialized array element type used whenever <type1> is given as
an :element-type argument to MAKE-ARRAY. Note that
(upgrade-array-element-type '<type>) =
(array-element-type (make-array 0 :element-type '<type>))
for all type specifiers <type>.
-- Change typep and subtypep so that:
(TYPEP X '(ARRAY <type>))
is true if and only if
(TYPEP X `(ARRAY ,(UPGRADE-ARRAY-ELEMENT-TYPE '<type>)))
is true.
-- Require that the resultant array-element-type from a call to make-array
is independent of any argument to make-array except for the
:element-type
argument. Thus upgrading, if done at all, must be done the same way for
non-simple and multi-dimensional arrays as it is for simple arrays.
-- Eliminate references to the distinction between types "for declaration"
and
"for discrimination" in the discussion of array element-types. This
would
include documentation patterened after CLtL:
a.) The discussion in section 4.5, p. 45 and 46
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are definitely
not
type-equivalent in a given implementation, but for which make-array will
return
an object of the same array type. Let this primitive type be (ARRAY
<aet-y>).
This will be an implementation dependent search, but in every
implementation
that the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, it should be true that:
(array-element-type (make-array 0 :element-type '<aet-x>)) ==> <aet-y>
(array-element-type (make-array 0 :element-type '<aet-y>)) ==> <aet-y>
To eliminate the distinction between "for declaration" and "for
discrimination"
both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for exactly
the
same set of objects, these names should be type-equivalent. In other words,
both describe those arrays specialized to hold elements of type <aet-y>.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that are upgraded
to
the same "element type" should be equivalent as element-type specifiers,
the
following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and "for
discrimination" for array type-specifiers. The suggested changes to the
interpretation of array type-specifiers follow from defining type
specifiers
as names for collections of objects, on typep being a set membership test,
and subtypep a subset test on collections of objects.
Current Practice:
Every vendor's implementation that the proposer has queried does some
amount
of non-trivial "upgrading"; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests
[A] and [C] part 2; this is a consequence of implementing the distinction
between "for declaration" and "for discrimination". Lucid and Xerox both
pass test [B], and the other vendors fail it.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification,
but only a small amount of work should be required in each vendor's
implementation of typep and subtypep.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely that
any
user code will have to be changed. In fact, it is more likely that some of
the
vendors will cease to get bug reports about make-array returning a result
that
isn't of "the obvious type".
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(make-array <n> :element-type '<type>) frequently is not of type
(array <type>) has been very confusing to almost everyone. That is,
in practice, the distinction between "for declaration" and
"for discrimination" has been a disaster.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration"
and "for discrimination" is a simplifying step -- it is a much simpler rule
to state that the type-specifiers actually describe the collections of data
they purport to name. Thus this is a step towards increased elegance.
Discussion:
To get a sense of how the community is confused, see the arpanet mailing
list for Common Lisp, in a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications".
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP
should
be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been
proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I
don't
see how to eliminate "array element type upgrading" without creating
more problems [than] we solve. . . .
My conclusion [JonL's] is that it isn't array types that are wrong, it
is
the
understanding of the meaning of TYPEP that is wrong.
Semantically, upgrade-array-element-type is equivalent to:
(defun upgrade-array-element-type (element-type)
(array-element-type (make-array 0 :element-type element-type)))
but it might not cons up the 0-element array first. Also, the presence of
this name, as a documented function in the language, would serve notice
that
"upgrading" is an important aspect of any real implementation of CL arrays.
Many persons are in favor of the permission to upgrade; but they would not
like to see CL become a language like C where there are a prescribed set of
kinds of arrays that must be implemented (e.g, "int", "long int", "single",
"double" etc), and no others can exist. In short, no one would want to
gain
portability at the expense of limiting the language to the architectural
features of the hardware on which it was first implemented.
It may also be the case that portability will be improved since the
identity
(typep (make-array N :element-type '<type>) '(array <type>)) will be
observed.
There is a strong feeling that the COMPLEX type should have a similar
handling as ARRAY type. This will be the subject of a separate cleanup
issue.
∂05-Oct-88 0110 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 01:10:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 01:06:38 PDT
Date: 5 Oct 88 01:06 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Rob.MacLachlan@WB1.CS.CMU.EDU's message of Sun, 18 Sep 88
11:09:11 EDT
To: Rob.MacLachlan@WB1.CS.CMU.EDU
cc: Eric Benson <eb@lucid.com>, masinter.pa@Xerox.COM,
BECKERLE@XX.LCS.MIT.EDU, cl-cleanup@sail.stanford.edu
Message-ID: <881005-010638-4535@Xerox>
I'm confident that Michael had no intention of proposing that there be a
new type (LIST NUMBER) of CONS whose CAR could only point to FIXNUM and
whose CDR could only point to NIL or (LIST NUMBER).
This is evident from the examples:
(typep x '(list <subtype>)) == (and (typep x 'list)
(typep (car x) <subtype>))
From a purist point of view, it might be deplorable that (LIST NUMBER) mean
something radically different than (VECTOR NUMBER). From a practical point
of view, this might be a minor inconsistency, especially in the context of
the rest of Common Lisp. Lists are mutable and can hold any type; vectors
are only mutable in fixed ways and can hold restricted types.
While I'm mildly opposed to such a proposal on the grounds that it is not a
useful addition, I would be even more strongly opposed to a proposal to add
a LIST type designator that made LIST have the same awkward subtype
semantics that ARRAY does.
∂05-Oct-88 0739 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 07:39:24 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Wed, 5 Oct 88 09:48:18 EDT
Received: by joplin.think.com; Wed, 5 Oct 88 10:26:46 EDT
Date: Wed, 5 Oct 88 10:26:46 EDT
From: gls@Think.COM
Message-Id: <8810051426.AA26682@joplin.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Sun, 2 Oct 88 21:34 EDT <881002213452.4.KMP@GRYPHON.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 1)
Date: Sun, 2 Oct 88 21:34 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
Issue: TEST-NOT-IF-NOT
...
My only complaint about this is that I use REMOVE-IF-NOT much more
frequently than REMOVE-IF.
--Guy
∂05-Oct-88 1102 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 11:02:02 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471008; Wed 5-Oct-88 14:00:39 EDT
Date: Wed, 5 Oct 88 14:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005140026.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
An updated copy to reflect discussion since the first draft:
- Corrected typo in description of COMPLEMENT (notice by Fahlman).
- Rewrote the rationale to reflect the e-mail discussion.
- Added endorsements in the Discussion section.
-----
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
Status: For Internal Discussion
Related-Issues: TEST-NOT-IF-NOT
Problem Description:
A number of useful functions on functions are conspicuously
absent from Common Lisp's basic set. Among them are functions
which return constant T, constant NIL, and functions which
combine functions in common, interesting ways.
Proposal (FUNCTION-COMPOSITION:NEW-FUNCTIONS):
Add the following functions:
COMPOSE &REST functions [Function]
Returns a function whose value is the same as the composition
of the given functions. eg, (FUNCALL (COMPOSE #'F #'G #'H) A B C)
is the same as (F (G (H A B C))). Also, for example, #'CAADR may
be described as (COMPOSE #'CAR #'CAR #'CDR).
CONJOIN &REST functions [Function]
Returns a function whose value is the same as the AND of the
given functions applied to the same arguments.
DISJOIN &REST functions [Function]
Returns a function whose value is the same as the OR of the
given functions applied to the same arguments.
COMPLEMENT function [Function]
Returns a function whose value is the same as the NOT of the
given function applied to the same arguments.
ALWAYS value [Function]
Returns a function whose value is always VALUE.
Examples:
(MAPCAR #'(LAMBDA (X) (DECLARE (IGNORE X)) T) '(3 A 4.3))
==
(MAPCAR (ALWAYS T) '(3 A 4.3))
=> (T T T)
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
(FUNCALL #'(LAMBDA (&REST X) (REVERSE (APPLY #'LIST* X))) 3 4 5 '(6 7))
==
(FUNCALL (COMPOSE #'REVERSE #'LIST*) 3 4 5 '(6 7))
=> (7 6 5 4 3)
(FIND-IF-NOT #'ZEROP '(0 0 3))
==
(FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
=> 3
Rationale:
The presence of these functions will contribute to syntactic
conciseness in some cases, and more importantly will permit
a programming style which is currently discouraged by most
Common Lisp implementations.
It is technically possible to define this functionality portably,
the really important part of this proposal is that native compiler
support is needed to really do them justice. Portable implementations
are not likely to be efficient enough for serious use.
Placing these functions in the core language not only permits
but encourages a very useful set of compiler optimizations that
would otherwise be difficult to obtain.
In principle, a proposal to flush the :TEST-NOT keywords and the
-IF-NOT functions could even be entertained if the COMPLEMENT
function were added. [See issue TEST-NOT-IF-NOT.]
Current Practice:
No Common Lisp implementations provide these primitives, but they do
exist in the T language.
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
((NOT (REST FUNCTIONS))
(FIRST FUNCTIONS))
(T
(LET ((REVERSED-FUNCTIONS (REVERSE FUNCTIONS)))
(LET ((LAST-FUNCTION (FIRST REVERSED-FUNCTIONS))
(OTHER-FUNCTIONS (REST REVERSED-FUNCTIONS)))
#'(LAMBDA (&REST ARGUMENTS)
(DO ((O OTHER-FUNCTIONS (CDR O))
(VAL (APPLY LAST-FUNCTION ARGUMENTS)
(FUNCALL (CAR O) VAL)))
((NULL O) VAL))))))))
(DEFUN CONJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL T (AND VAL (APPLY (CAR F) ARGUMENTS))))
((OR (NULL VAL) (NULL F)) VAL))))
(DEFUN DISJOIN (&REST FUNCTIONS)
#'(LAMBDA (&REST ARGUMENTS)
(DO ((F FUNCTIONS (CDR F))
(VAL NIL (OR VAL (APPLY (CAR F) ARGUMENTS))))
((OR VAL (NULL F)) VAL))))
(DEFUN COMPLEMENT (FUNCTION)
#'(LAMBDA (&REST ARGUMENTS)
(NOT (APPLY FUNCTION ARGUMENTS))))
(DEFUN ALWAYS (VALUE)
#'(LAMBDA (&REST ARGUMENTS)
(DECLARE (IGNORE ARGUMENTS))
VALUE))
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
(COMPLEMENT BENEFITS)
Benefits:
Some code would be more clear.
Some compilers might be able to produce better code.
Takes a step toward being able to flush the -IF-NOT functions
and the :TEST-NOT keywords, both of which are high on the list
of what people are referring to when they say Common Lisp is
bloated by too much garbage.
Aesthetics:
In situations where these could be used straightforwardly, the
alternatives are far less perspicuous.
Discussion:
Pitman and van Roggen support the proposal.
Jim McDonald (JLM@Lucid.COM) seemed supportive of this proposal
and even suggested adding more elaborate operators such as
PERMUTE and COMMUTE. eg, (COMMUTE #'CONS) would be like what
Maclisp called XCONS.
Masinter wavered on this issue, but currently seems to support it.
Fahlman thinks this slightly gratuitous but is not opposed to
it if others think it is a good idea.
∂05-Oct-88 1105 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 11:05:34 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471013; Wed 5-Oct-88 14:04:22 EDT
Date: Wed, 5 Oct 88 14:04 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005140414.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I added a new option `FLUSH-TEST-NOT' in addition to `FLUSH-ALL.'
I also changed the Discussion to show people's support (or lack
thereof) and other misc notes of interest. The rest is unchanged.
I'm inclined to believe that if we cannot get consensus within the
Cleanup group, this should be presented to X3J13 with both options
so if the FLUSH-ALL option is not satisfactory, there's half a
chance we can get people to buy in on at least the FLUSH-TEST-NOT
option.
-----
Issue: TEST-NOT-IF-NOT
References: Functions offering a :TEST-NOT keyword:
ADJOIN (p276), ASSOC (p280), COUNT (p257), DELETE (p254),
DELETE-DUPLICATES (p254), FIND (p257),
INTERSECTION (p277), MEMBER (p275), MISMATCH (p257),
NINTERSECTION (p277), NSET-DIFFERENCE (p278),
NSET-EXCLUSIVE-OR (p278), NSUBLIS (p275), NSUBST (p274),
NSUBSTITUTE (p256), NUNION (p276), POSITION (p257),
RASSOC (p281), REMOVE (p253), REMOVE-DUPLICATES (p254),
SEARCH (p258), SET-DIFFERENCE (p278),
SET-EXCLUSIVE-OR (p278), SUBLIS (p274), SUBSETP (p279),
SUBST (p273), SUBSTITUTE (p255), TREE-EQUAL (p264),
UNION (p276);
Functions with "-IF-NOT" in their name:
ASSOC-IF-NOT (p280), COUNT-IF-NOT (p257),
DELETE-IF-NOT (p254), FIND-IF-NOT (p257),
MEMBER-IF-NOT (p275), NSUBST-IF-NOT (p274),
NSUBSTITUTE-IF-NOT (p256), POSITION-IF-NOT (p257),
RASSOC-IF-NOT (p281), REMOVE-IF-NOT (p253),
SUBST-IF-NOT (p273), SUBSTITUTE-IF-NOT (p255);
Issue FUNCTION-COMPOSITION
Category: CHANGE
Edit history: 02-Oct-88, Version 1 by Pitman (just FLUSH-ALL)
05-Oct-88, Version 2 by Pitman (add option FLUSH-TEST-NOT)
Status: For Internal Discussion
Problem Description:
The -IF-NOT functions are functionally unnecessary.
The :TEST-NOT keywords are not only functionally unnecessary but
also problematic because it's not clear what to do when both :TEST
and :TEST-NOT are provided.
Many people think Common Lisp is more `bloated' than it needs
to be and these aspects of the language are commonly cited
specific examples.
Proposal (TEST-NOT-IF-NOT:FLUSH-ALL):
Remove all -IF-NOT functions (named above) from Common Lisp.
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler.
The removal of :TEST-NOT also makes the language easier to explain.
Cost to Implementors:
Very slight.
Some symbols would disappear from the LISP package but could
still be offered in proprietary packages if deemed important
enough.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Proposal (TEST-NOT-IF-NOT:FLUSH-TEST-NOT):
Remove the :TEST-NOT keyword from the Common Lisp functions which
currently provide them (named above).
Rationale:
This makes the language a bit simpler and easier to explain.
Cost to Implementors:
Very slight.
Implementations could compatibly retain the :TEST-NOT keywords
for an interim period.
Current Practice:
Presumably no one has done this yet.
Cost to Users:
Some rewrites would be needed.
Those rewrites, which are already fairly simple, would be even
more simple if some form of the FUNCTION-COMPOSITION issue is
voted in -- in particular, the COMPLEMENT function which it
proposes would help enormously in this regard.
Cost of Non-Adoption:
Common Lisp would continue to be what some people feel is
"bigger than it needs to be".
Benefits:
The cost of non-adoption would be avoided.
Aesthetics:
Presumably this makes the language easier to teach.
Discussion:
Moon expressed reservations about FLUSH-ALL (in Version 1, where
FLUSH-TEST-NOT was not offered) because it was such an incompatible
change.
Steele (commenting on Version 1) noted that his main reservation to
FLUSH-ALL is that he uses REMOVE-IF-NOT much more than REMOVE-IF.
Pierson, Dalton and Pitman support the combination of
TEST-NOT-IF-NOT:FLUSH-ALL (and FUNCTION-COMPOSITION:NEW-FUNCTIONS)
in spite of the incompatible change because of the aesthetic appeal.
This issue is related to FUNCTION-COMPOSITION, but is not dependent
on it.
van Roggen points out that a long time ago, he suggested dropping
-IF-NOT and :TEST-NOT, adding a function such as COMPLEMENT, and
adding a #~ readmacro such that
(FIND-IF-NOT #'ZEROP '(0 0 3))
== (FIND-IF (COMPLEMENT #'ZEROP) '(0 0 3))
== (FIND-IF #~ZEROP '(0 0 3))
Richard Mlynarik suggests that even the -IF functions provide
little extra use since
(xxx-IF test sequence ...)
can be rewritten
(xxx test sequence :test #'funcall).
He says he doesn't care what we do with this issue, however, since
he will just continue to use [MIT-style] LOOP in cases where these
sequence functions would seem to be called for.
∂05-Oct-88 1121 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 11:21:21 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471023; Wed 5-Oct-88 14:19:06 EDT
Date: Wed, 5 Oct 88 14:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
To: Gray@DSG.csc.ti.com
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2800915811-11749067@Kelvin>
Message-ID: <881005141854.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 3 Oct 88 19:10:11 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> Early binding of function names to function definitions is generally
> inhibited in Common Lisp because CLtL says the compiler must assume
> that any opaque function call might change the definition of a
> function in between calls to that function.
Is there a specific place in CLtL that clearly says that, or is it
just inferred from the ability to SETF SYMBOL-FUNCTION without
restrictions on where or when?
Just inferred. Why?
> Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT-EARLY-BINDING):
>
> Permit early binding in some situations, but do not require them.
This doesn't define what "early binding" means. The test cases suggest
what the intent is, but I'm not comfortable with specification by
example.
Can you suggest a wording?
In particular, it isn't clear whether you intend to affect the
case of one function calling another, or if you are only talking about
functions that reference their own definition.
I see no reason to distinguish. Do you agree? If not, can you please make
a case for why a function referencing itself should be different than a
function referencing another function. This is the kind of thing I worry
about:
(SETQ FACT '(LAMBDA (X) (COND ((ZEROP X) 1) (T (* X (FACT (- X 1)))))))
(COMPILE 'FACT FACT)
vs (SETF (SYMBOL-FUNCTION 'FACT) (COMPILE NIL FACT)).
Any difference in behavior/efficiency of these two forms would seem
highly gratuitous to me.
> Specifically, with SPEED=0, the compiler should not do early binding
> (for the sake of tracing, stack debugging, and reloading in
> interactive debugging), ...
Given that intent, if proposal OPTIMIZE-DEBUG-INFO:NEW-QUALITY is
adopted, then a more appropriate criteria might be DEBUG>SPEED.
Actually, though, if debugability is the issue, this might be beyond
what the standard ought to specify, since nowhere else does it specify
what happens at particular optimization levels.
If the new quality passes, I think we should haggle about this. I write
my proposals based on what's true at the time they will be voted on.
Right now, there's little guidance about the qualities, and DEBUG is
not one. The note in the Discussion about this is intended to handwave
this issue. I could expand the note or move it to the proposal section
if you thought it really important.
> ... but with in other with higher speed settings, ...
The grammar didn't come out right on that.
Right.
> regardless of the OPTMIZE SPEED setting.
OPTIMIZE
Right.
> of the OPTMIZE SPEED setting.
ditto
Hmmm. I detect a pattern.
> Current Practice:
>
> Symbolics Genera and Symbolics Cloe not currently do early binding.
"not" -> "do not"
Right.
> David Gray has expressed reservations about this to the OPTIMIZE SPEED
> quality at all since he sees it as a semantic issue.
... about tying this to the OPTIMIZE qualities ...
Actually, I thought _you_ were presenting it as a semantic issue.
Only in the sense that the current description forces it to be. By
saying that SYMBOL-FUNCTION holds the function that will be called, CLtL
really tied our hands. This proposal is trying to get away from that and
make it an efficiency/debugging issue rather than a semantic issue.
Does that make sense?
Thanks for your careful reading and criticism.
∂05-Oct-88 1145 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 11:45:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 471051; 5 Oct 88 14:43:24 EDT
Date: Wed, 5 Oct 88 14:43 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 3)
To: Jonl@Lucid.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8806100921.AA27396@bhopal.lucid.com>
Message-ID: <881005144312.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 10 Jun 88 02:21:54 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: Moon@Stony-Brook.SCRC.Symbolics.COM
I intend to put some more work in on this proposal later today (Friday)
which will, among other things, incorporate some of your suggestion; but
others of your comments I'm not sure what to do with.
...
I have no record of any such proposal going out. I was going to try to
bring myself up to date on this discussion but I'm going to put it off
until I have an up-to-date copy of the proposal.
∂05-Oct-88 1151 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 11:51:14 PDT
Received: by ti.com id AA10789; Wed, 5 Oct 88 13:49:36 CDT
Received: from Kelvin by tilde id AA26823; Wed, 5 Oct 88 13:35:29 CDT
Message-Id: <2801068586-4412902@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88 13:36:26 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: peck@SUN.COM
Cc: Kent M Pitman <KMP@SCRC-STONY-BROOK.ARPA>, CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: TAGBODY-CONTENTS (Version 3)
In-Reply-To: Msg of Tue, 04 Oct 88 15:15:49 -0700 from peck@SUN.COM
> Is anybody concerned about macros that expand to a tagbody with NIL forms?
> If NIL is a statement in a tagbody then they disappear quietly,
> especially after a pass by a good compiler.
> With the current proposal, though, one will get:
> "ERROR: Multiple appearances of tag NIL."
>
> I don't know what current practice is, if code like this has
> always signalled an error then this is a total non-issue.
> If not, it might be noted as a possible conversion cost.
The Explorer permits using NIL as a GO tag, but as a special case, does
not warn about multiple appearances of NIL.
∂05-Oct-88 1203 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 12:03:03 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471066; Wed 5-Oct-88 15:00:56 EDT
Date: Wed, 5 Oct 88 15:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 3)
To: Gray@DSG.csc.ti.com
cc: peck@SUN.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <2801068586-4412902@Kelvin>
Message-ID: <881005150038.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 5 Oct 88 13:36:26 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> Is anybody concerned about macros that expand to a tagbody with NIL forms?
> If NIL is a statement in a tagbody then they disappear quietly,
> especially after a pass by a good compiler.
> With the current proposal, though, one will get:
> "ERROR: Multiple appearances of tag NIL."
>
> I don't know what current practice is, if code like this has
> always signalled an error then this is a total non-issue.
> If not, it might be noted as a possible conversion cost.
The Explorer permits using NIL as a GO tag, but as a special case, does
not warn about multiple appearances of NIL.
Hmmm. That suggests another alternative: We could leave NIL being a tag
and just say that it's an error to repeat a tag only if you also GO to
it. That would mean that other tags could be repeated as well. eg, I
seem to recall that some people put ------ in their tagbodies as
separators between major sections. As long as they didn't also do (GO
-----), their practice would be legitimized.
∂05-Oct-88 1207 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 2)
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 5 Oct 88 12:07:25 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA02685; Wed, 5 Oct 88 15:07:08 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA29141; Wed, 5 Oct 88 15:08:55 EDT
Message-Id: <8810051908.AA29141@mist.UUCP>
To: Kent M Pitman <KMP%STONY-BROOK.SCRC.Symbolics.COM@multimax>
Cc: CL-Cleanup%SAIL.Stanford.EDU@multimax
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 2)
In-Reply-To: Your message of Wed, 05 Oct 88 14:00:00 -0400.
<881005140026.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 05 Oct 88 15:08:52 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
(MAPCAR #'(LAMBDA (X) (AND (NUMBERP X) (ZEROP X))) '(3 A 0.0))
==
(MAPCAR (CONJOIN #'NUMBERP #'ZEROP) '(3 A 0.0))
=> (NIL NIL T)
(FIND-IF #'(LAMBDA (X) (AND (INTEGERP X) (SYMBOLP X))) '(3.0 A 4))
==
(FIND-IF (DISJOIN #'INTEGERP #'SYMBOLP) '(3.0 A 4))
=> A
Shouldn't that be #'(LAMBDA ... (OR ...))?
Pitman and van Roggen support the proposal.
You can add me as a supporter.
∂05-Oct-88 1221 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 12:20:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA02779g; Wed, 5 Oct 88 11:18:36 PST
Received: by bhopal id AA01503g; Wed, 5 Oct 88 12:18:13 PDT
Date: Wed, 5 Oct 88 12:18:13 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810051918.AA01503@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 5 Oct 88 00:57 PDT <881005-005724-4531@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
I'm disturbed by the consensus that seems to have formed around the
issue of upgrading array types. In particular, I'd like someone to
point out why you can't simply require
(equal (array-element-type (make-array n :element-type x))
x)
for all legal types x.
As far as I can tell, all you have to do is store x in the header
information of the array, for later retrieval whenever type issues
must be resolved.
Since the internal implementation type y may differ from x,
UPGRADE-ARRAY-ELEMENT-TYPE becomes a merely informative routine that
users can employ to understand the efficiency with with their code is
implemented. I can think of no other valid reason for a user to care
about the internal representation, with the possible exception of
interfacing to foreign code.
In particular, any code that attempts to put objects of type y into an
array declared with type x is guaranteed to lose for some
implementation unless x and y are equivalent types. This should be
reflected in signalled errors when safety is high. If someone wants
to put 213 into an array, then they had better have created it with an
element-type that is a super-type of (integer 213 213).
(unsigned-byte 8) will work, (unsigned-byte 5) will not.
I.e., with safety 3, setf should type check against the declared, not
the internal, type. With safety 1 or 2, it might check against the
internal type (presumably a cheaper test).
This is extremely simple to understand and to implement. I think any
alternative to what I am presenting here adds enough complexity and
non-portability to the language to require a very solid and explicit
justification.
jlm
∂05-Oct-88 1342 CL-Cleanup-mailer Issue: FUNCTION-COMPOSITION (Version 2)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 13:42:31 PDT
Return-Path: <gls@Think.COM>
Received: from joplin.think.com ([192.31.181.10]) by Think.COM; Wed, 5 Oct 88 15:51:56 EDT
Received: by joplin.think.com; Wed, 5 Oct 88 16:32:02 EDT
Date: Wed, 5 Oct 88 16:32:02 EDT
From: gls@Think.COM
Message-Id: <8810052032.AA26451@joplin.think.com>
To: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
In-Reply-To: Kent M Pitman's message of Wed, 5 Oct 88 14:00 EDT <881005140026.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-COMPOSITION (Version 2)
Date: Wed, 5 Oct 88 14:00 EDT
From: Kent M Pitman <KMP@stony-brook.scrc.symbolics.com>
...
Issue: FUNCTION-COMPOSITION
References: None
Category: ADDITION
Edit history: 21-Jun-88, Version 1 by Pitman
05-Oct-88, Version 2 by Pitman
Status: For Internal Discussion
Related-Issues: TEST-NOT-IF-NOT
...
Cost to Implementors:
A straightforward implementation is simple to cook up. The definitions
given here would suffice. Typically some additional work might be
desirable to make these open code in interesting ways.
(DEFUN COMPOSE (&REST FUNCTIONS)
(COND ((NOT FUNCTIONS)
(ERROR "COMPOSE requires at least one function."))
...
Sorry I didn't catch this earlier. I believe that this should read
(COND ((NULL FUNCTIONS) #'IDENTITY)
...
(1) IDENTITY is the identity element for the COMPOSE operation.
(Actually not quite, in the case where the rightmost function
accepts more than one argument, but close enough.)
(2) NULL is more appropriate than NOT (this is a nit).
--Guy
∂05-Oct-88 1353 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 2)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 13:52:44 PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA06039; Wed, 5 Oct 88 13:46:44 PDT
Received: from denali.sun.com by snail.sun.com (4.0/SMI-4.0)
id AA18198; Wed, 5 Oct 88 13:49:37 PDT
Received: from localhost by denali.sun.com (3.2/SMI-3.2)
id AA13846; Wed, 5 Oct 88 13:51:25 PDT
Message-Id: <8810052051.AA13846@denali.sun.com>
To: gls@Think.COM
Cc: KMP@stony-brook.scrc.symbolics.com
Cc: CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 2)
In-Reply-To: Your message of Wed, 05 Oct 88 16:32:02 -0400;
<8810052032.AA26451@joplin.think.com> .
Date: Wed, 05 Oct 88 13:51:23 -0700
From: peck@Sun.COM
>Sorry I didn't catch this earlier. I believe that this should read
>
> (COND ((NULL FUNCTIONS) #'IDENTITY)
> ...
>
>(1) IDENTITY is the identity element for the COMPOSE operation.
> (Actually not quite, in the case where the rightmost function
> accepts more than one argument, but close enough.)
How about:
(COND ((NULL FUNCTIONS) #'VALUES)
...
This will accept multiple arguments.
ps, Anybody want to make a MULTIPLE-VALUE-CALL version of COMPOSE?
∂05-Oct-88 1416 CL-Cleanup-mailer Issue: NTH-VALUE (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 14:16:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 13:45:13 PDT
Date: 5 Oct 88 13:45 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: NTH-VALUE (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005-134513-1235@Xerox>
change Current Practice as per Gray. I'm no longer sure if
I'm in favor of the proposal; I'd guess I'm neutral.
I just re-read McCarthy's note about Lisp standards and
"intellectual logrolling", and it makes me pause. (I'll forward
the note to X3J13.)
!
Issue: NTH-VALUE
References: Multiple values, pp. 133-139
Category: ADDITION
Edit history: 16-Aug-88, Version 1 by Pierson
01-Oct-88, Version 2 by Pitman (minor edits)
5-Oct-88, Version 3 by Masinter
(add Current Practice as per Gray)
Problem description:
The set of operations on multiple values in Common Lisp is incomplete:
The only ways to retrieve just one of several return values (other than
the first) are:
- Bind several variables and then ignore all but one.
eg, (MULTIPLE-VALUE-BIND (X Y Z) <exp> (DECLARE (IGNORE X Y)) Z)
This is somewhat cumbersome to write and not perspicuous.
- Get a list of all return values and select from that.
eg, (THIRD (MULTIPLE-VALUE-LIST <exp>))
This is somewhat cumbersome, not perspicuous, and creates
needless garbage.
Proposal (NTH-VALUE:ADD):
Add a new macro NTH-VALUE, described as
NTH-VALUE n form [Macro]
Evaluates the FORM and returns the Nth value returned by the form as
a single value. N is 0-based, i.e. the first returned value is
value 0 (for consistency with NTH and NTHCDR). Both N and FORM are
evaluated, in left-to-right order.
Test Cases/Examples:
With this proposal MOD could be defined as:
(DEFUN MOD (NUMBER DIVISOR)
(NTH-VALUE 1 (FLOOR NUMBER DIVISOR)))
The same code would currently be:
(DEFUN MOD (NUMBER DIVISOR)
(MULTIPLE-VALUE-BIND (DIVIDEND REMAINDER)
(FLOOR NUMBER DIVISOR)
(DECLARE (IGNORE DIVIDEND))
REMAINDER))
Rationale:
This corrects the stated problem.
Current practice:
The TI Explorer and LMI Lambda have this feature.
Cost to Implementors:
Writing the macro version is fairly straightforward.
Some will choose to implement compiler hooks so that code written with
NTH-VALUE will be as efficient as possible. This may involve some
additional work, but presumably nothing major.
Cost to Users:
This is an upward-compatible change.
Cost of non-Adoption:
The occassional code where this comes up may be one or more of
clumsier to write, more difficult to read, or less efficient.
(The feature is rarely used in implementations that have it.)
Benefits:
The cost of non-adoption is avoided.
Aesthetics:
While it does add another function to the language it removes
some need for the hairier multiple-value forms.
Discussion:
Pitman proposed this in the very late pre-CLtL days. It was
rejected then because it was too late in the cycle.
There was not strong sentiment for including this feature
in Common Lisp, but no active opposition.
∂05-Oct-88 1417 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 14:17:10 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 05 OCT 88 14:14:17 PDT
Date: 5 Oct 88 14:13 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
In-reply-to: Jim McDonald <jlm@lucid.com>'s message of Wed, 5 Oct 88
12:18:13 PDT
To: Jim McDonald <jlm@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <881005-141417-1355@Xerox>
"I'd like someone to
point out why you can't simply require
(equal (array-element-type (make-array n :element-type x))
x)
for all legal types x."
a) nobody does it
b) its not very useful
I thought this was in the discussion section, but it seems to be hidden.
∂05-Oct-88 1417 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 14:16:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 14:09:38 PDT
Date: 5 Oct 88 14:08 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 3)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <880923-011503-3968@Xerox>
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Symbols on the LISP package may have function or macro
definitions, top level value or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be functions or macros,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
(The proposal LISP-SYMBOL-REDEFINITION addresses the
converse; that is, what user programs are allowed to do.)
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available.
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it may
not be bound, defined as a type, or defined as a function, macro or
special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in CLtL,
there can be extra definitions for those symbols. For example, in Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of suppositions
about what is in what package, and the changes could potentially be extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This issue came up a while back on Common-Lisp list. The issue
of whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
∂05-Oct-88 1510 CL-Cleanup-mailer Re: Potential Clean-Up Issues
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:10:03 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 14:49:52 PDT
Date: 5 Oct 88 14:48 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Potential Clean-Up Issues
In-reply-to: your message of 5 Oct 88 16:44 EDT
To: ROSENKING@A.ISI.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881005-144952-1509@Xerox>
This is the format for cleanup proposals. Perhaps you could
try to cast them in this format?
For the CL-CLEANUP group:
I made some minor changes to the proposal format to separate
Test Case from Example, make Performance Impact a separate
section, etc. I thought I'd distribute this again at X3J13.
This is a little late in the cycle, since no new proposals for
additions will be accepted after this meeting, but I expect
some issues to arise out of the editorial review, and as a result
of the incorporation of the results of the Object, Condition,
Iteration, Compiler, and Character committees.
!
Format for proposals to the cleanup committee (Version 14)
October 5, 1988
Replace the text below in >> double inverted angle-brackets <<. Be
brief; leave testimonials and personal opinions to the discussion at the
end. Be complete; do not expect someone else to fix or redesign parts.
Spell out names (e.g., Masinter rather than LMM) and upper-case all Lisp
symbols (DEFUN rather than Defun). I like it better if you write in the
third person rather than first.
Remember that this is a proposal to a change to the standard
for Common Lisp, not recommendations to the editor, not
a set of recommendations to Common Lisp implementors.
Issue: >>A short descriptive label, which starts with a name
which occurs in the index of CLtL, and be a suitable
symbol in the Common Lisp style, e.g., CDR-TERMINATION.
When in doubt, let the cleanup committee assign the name.
The name should match the problem description, not the
proposal.<<
References: >>The pages of CLtL which describe the feature being
discussed, and other references.<<
Related issues: >> names of other cleanup issues about the same topic.<<
Category: >>One or more of:
CLARIFICATION -- proposal to resolve an ambiguity or case
of under-specified situation in CLtL, where this
ambiguity interferes with portability of code.
CHANGE -- proposal for an incompatible change.
ADDITION -- proposal for a compatible extension<<
Edit history: >>Author and date of submission (version 1), and author
and date of subsequent versions.<<
Problem description:
>>Describe the problem being addressed -- why is the current situation
unclear or unsatisfactory? Avoid describing the proposal here or arguing
for its adoption. <<
Proposal (>>issue-label:proposal-label<<): >> Describe as precisely as
possible what you are proposing. This can take the form of
text that could be dropped into the new specification document.
Proposals should be for changes to Common Lisp, rather than changes to
CLtL. If necessary, propose a set of labelled alternatives here, rather
than a single proposal. Each proposal must be a complete design; do not
leave out details. Avoid arguing for the proposal here, just describe
it.<<
Examples:
>> Examples are samples of Common Lisp code that illustrates the issue.
along with explanatory text. Please explain what the examples should
do, do in current implementations, and any special tricks.<<
Test Cases:
>> Test Cases are simple stand-alone expressions which are valid and
do not signal an error if the proposal is adhered to. (Use ASSERT
if needed.) Omit if you have none.
<<
Rationale:
>> A one or two sentence summary of the arguments that follow. <<
Current practice:
>>Do some/many/no Common Lisp implementations already work this way?
Survey independent Common Lisp implementations - preferably three or
more. What do they do on the test cases or examples? What do current
user programs do? Are there textbooks which describe this feature? <<
Cost to Implementors:
>>What is the cost to implementors of adopting the proposal? How much
implementation effort is required? Is public-domain code available? For
pervasive changes, can the conversion be automated?<<
Cost to Users:
>>For incompatible changes, what is the cost to users of converting
existing user code? To what extent can the process be automated? How?<<
Cost of non-adoption:
>>How serious is it if nothing is done? <<
Performance impact:
>> what does the proposal do to better or worsen the size or speed
of user programs and implementations? <<
Benefits:
>>What is better if the proposal is adopted? How serious is the problem
if just left as it is? <<
Esthetics:
>>How does this proposal affect the simplicity of the language, ease of
learning, etc. You can spell it aesthetics if you like. <<
Discussion:
>> Additional arguments, discussions, endorsements, testimonials, etc.
should go here. Testimonials are the least effective; the discussion should
be useful to someone not already with the issue or those discussing it.
Avoid a blow-by-blow account of debates or recounting of history. <<
∂05-Oct-88 1511 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:11:30 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03017g; Wed, 5 Oct 88 14:08:33 PST
Received: by bhopal id AA01980g; Wed, 5 Oct 88 15:08:10 PDT
Date: Wed, 5 Oct 88 15:08:10 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810052208.AA01980@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: David A. Moon's message of Mon, 3 Oct 88 22:30 EDT <19881004023059.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: TEST-NOT-IF-NOT (Version 1)
re: ... [aesthetics] and that consideration changed my opposition to this
proposal from vehement to mild. The only reason I'm opposed now is
that I'm opposed on principle to incompatible changes in mature languages.
My feelings exactly; except that I'd favor "incompatible changes in
mature languages" where there is a clear flaw in some feature that
has a reasonable probability of adversely impacting at least a few users.
To me, the :TEST/:TEST-NOT problem is stylistic rather than fundamental.
-- JonL --
∂05-Oct-88 1543 CL-Cleanup-mailer Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:42:45 PDT
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471338; Wed 5-Oct-88 18:41:09 EDT
Date: Wed, 5 Oct 88 18:40 EDT
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-E-EXPONENT-SIGN (Version 2)
To: KMP@STONY-BROOK.SCRC.Symbolics.COM, masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu, GLS@Think.COM
In-Reply-To: <881002162430.7.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881005224056.3.CASSELS@GROUSE.SCRC.Symbolics.COM>
Date: Sun, 2 Oct 88 16:24 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I don't care about PRIN1 and ~E being compatible, particularly, but it's
my vague recollection that some of the way ~E, ~G, and ~F are set up is
to be compatible with some Fortran programs to make translation easy.
The proposal in these terms is that PRIN1 and ~E be (slightly)
incompatible, so that ~E can be internally consistent.
I
don't recall the details, but I even recall we talked half-seriously about
putting in Cobol picture-mode as well. I think that if this was a goal,
that we should make sure we don't accidentally violate that goal.
As long as the proposed change is not going to cause problems for people
doing translation of Fortran programs, I'm happy with the change.
Since ~E is being made self-consistent, the proposal should make it
easier for people doing translation of Fortran programs. Note that the
CL formats do not correspond character for character with Fortran, but
give the same general capability.
I don't remember the details of this issue nor do I have a fortran
specification handy but maybe GLS or someone else reading this message
remembers the issue. Based on what other people remember about the
issue, it may be useful to mention that it was considered in the
Discussion.
∂05-Oct-88 1551 CL-Cleanup-mailer Re: Issue: PACKAGE-CLUTTER (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:51:31 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 15:28:14 PDT
Date: 5 Oct 88 15:15 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: PACKAGE-CLUTTER (Version 3)
In-reply-to: masinter.pa's message of 5 Oct 88 14:08 PDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005-152814-1619@Xerox>
I forgot to include the summary of changes at the beginning of the message.
I think I responded to most of the criticisms; I left the prohibitions of
what the user might do to LISP-SYMBOL-REDEFINITION, expanded on the problem
description, current practice and description sections.
∂05-Oct-88 1558 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 15:58:06 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03107g; Wed, 5 Oct 88 14:55:15 PST
Received: by bhopal id AA02053g; Wed, 5 Oct 88 15:54:49 PDT
Date: Wed, 5 Oct 88 15:54:49 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810052254.AA02053@bhopal>
To: sandra%defun@cs.utah.edu
Cc: Moon@stony-brook.scrc.symbolics.com, eb@SAIL.Stanford.EDU,
cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Oct 88 22:00:24 MDT <8810040400.AA13928@defun.utah.edu>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
re: It makes sense to be able to have more than one distinct remote
environment around at any given time; ...
Does it make any sense to have more than one distinct local
environment around, or is there only one?
Lucid's "retargetable" compiler indeed contains, potentially, dozens
of encapsulations of "remote environments" as so-called "compiler
machines". The idea is to cross-compile from an image running on, say,
a Sun3 to targets as diverse as the SPARC and 80386 at essentially
"the same time". See our paper in the 1986 Lisp Conferences on a
Dynamically Retargetable Compiler.
I had imagined that "local" environment meant the purely syntatic
information directly visible in the s-expression being viewed as
code; e.g., what names appear in a lambda or let binding, what
names appear in declare forms, etc. Is that more limiting that
what you had in mind?
I've given eb (Eric Benson) extensive comments on this proposal
verbally, and will not repeat them here. He is preparing a new
version incorporating the various ideas that have arisen during
the past couple days, and will mail that out shortly.
-- JonL --
∂05-Oct-88 1612 CL-Cleanup-mailer Issue: EXPT-RATIO (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 16:11:59 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03127g; Wed, 5 Oct 88 15:09:25 PST
Received: by bhopal id AA02105g; Wed, 5 Oct 88 16:09:00 PDT
Date: Wed, 5 Oct 88 16:09:00 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810052309.AA02105@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@sail.stanford.edu, JGA@STONY-BROOK.SCRC.Symbolics.COM,
Cassels@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David A. Moon's message of Tue, 4 Oct 88 15:14 EDT <19881004191447.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: EXPT-RATIO (Version 1)
Lucid implements the proposal -- namely (expt x 3/2) is about -1, modulo
roundoff. [Incidentally, the "roundoff" problem means that the result
is a complex number with a rather small imaginary part.]
-- JonL --
∂05-Oct-88 1725 CL-Cleanup-mailer Issue: KILL-PACKAGE (Version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 5 Oct 88 17:25:23 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03192g; Wed, 5 Oct 88 16:22:56 PST
Received: by bhopal id AA02227g; Wed, 5 Oct 88 17:22:31 PDT
Date: Wed, 5 Oct 88 17:22:31 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810060022.AA02227@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Tue, 4 Oct 88 18:04 EDT <881004180459.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: KILL-PACKAGE (Version 3)
re: Current Practice:
. . .
Lucid Common Lisp provides DELETE-PACKAGE but the argument must be a
package object.
Nope. It works with "packages" exactly as the rest of this proposal says.
re: Proposal (KILL-PACKAGE:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
Although this is the current Lucid practice, EB and I prefer to just
return NIL here. We must consider that DELETE-PACKAGE is only the
tip of the iceberg for retracting global data structures. There really
needs to be a DELETE-DEFSTRUCT and DELETE-DEFTYPE too. So whatever is
done for the error semantics of one of these ought to be consistent
for all three.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package as it would have if no conflict had
occurred.
I wouldn't use the word "conflict" here, since it has a technical meaning
in the context of packages (CLtL p178) that is somewhat counter to its
use here.
The principal effect of deleting the package is that the name and
nicknames of the designated package cease to be recognized package
names.
Any symbols in the designated package still exist after this function
is called. If their home package was not the package to be deleted, the
home package will be unchanged. If their home package was that package,
the home package after this operation is unspecified; the effect of
printing such symbols is also unspecified.
The phrase "still exist" seems odd to me. Perhaps a better way to say it
is that the symbols entered in a package are not modified except possibly
for the symbol-package slot of those homed in that package.
The designated package persists after this function is called.
PACKAGEP is still true of it, but PACKAGE-NAME will return NIL.
The effect of any other package operation on PACKAGE once it has been
deleted is undefined.
Again, the word "persists" is confusing to me. What else could it do?
automatically, self-GC? A single sentence encapsulating what you are
trying to say here could go into the above paragraph: "The principal
effect ...".
DELETE-PACKAGE returns T (if the deletion attempt was successful).
and NIL otherwise?
-- JonL --
∂05-Oct-88 1934 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
Received: from ACORN.CS.ROCHESTER.EDU by SAIL.Stanford.EDU with TCP; 5 Oct 88 19:34:00 PDT
Received: from DOUGHNUT.CS.ROCHESTER.EDU by ACORN.CS.ROCHESTER.EDU via INTERNET with SMTP id 59502; 5 Oct 88 22:21:29 EDT
Date: Wed, 5 Oct 88 22:23 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: common-lisp-object-system@SAIL.STANFORD.EDU, cl-cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881005-152958-1624@Xerox>
Message-ID: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Sender: miller@CS.ROCHESTER.EDU
Reply-To: miller@CS.ROCHESTER.EDU
Organization: University of Rochester, Department of Computer Science
Postal-address: 610 CS Building, Comp Sci Dept., U. Rochester, Rochester NY 14627
Phone: 716-275-1118
I'd like to propose an alternative (or rather elaboration) to
EVAL-OTHER:SELF-EVALUATE, currently...
Proposal (EVAL-OTHER:SELF-EVALUATE):
Standard data types (those mentioned by CLtL) other than those for which
a more explicit evaluation rule exists would be defined to self-evaluate.
Such data types include, for example, structures, arrays, vectors, and
pathnames.
Structure types defined by users using DEFSTRUCT should also self-evaluate
unless an explicit implementation type for the structure is given in the
DEFSTRUCT, in which case the rule for evaluation of that type should be
used. (This is important in the case of type LIST.)
I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
explicitly specifies the eval behavior.
Rational:
When using lisp to build an embedded language, one can already define via a
DEFSTRUCT option what the printer for the object should be. One can also,
via character macros define a specific parse behavior. One cannot, however,
currently define an EVAL behavior. For example, I can define #\[ and #\] to
denote the beginning and end of information for consing a structure FOO via
character macros which will print the same way.
e.g. [A FOO] may really be internally #S(FOO SLOT1: A SLOT2: FOO SLOT3: NIL)
what I may want to define is that (cons [A FOO] [B FOO]) return (A B)
because the EVAL option on foo returned the value of SLOT1.
In general, one could define that instances and structure objects (the
latter are probably instances given CLOS) all handle an EVAL message which
the user can use to explicitly define the behavior. The default handler
returns the object itself, which is compatible with the
EVAL-OTHER:SELF-EVALUATE proposal already made.
Similar arguments to the above can be made for APPLY. The ultimate idea is
that user created objects can be treated as first class objects, just like
symbols.
Comments?
----
Brad Miller U. Rochester Comp Sci Dept.
miller@cs.rochester.edu {...allegra!rochester!miller}
∂05-Oct-88 2032 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 20:31:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471496; Wed 5-Oct-88 23:30:42 EDT
Date: Wed, 5 Oct 88 23:30 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005233028.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
I felt pretty good about this compromise solution. I hope others
will, too. It permits duplicated tags if they are unused, and it
permits (GO NIL). Hopefully that will make everything that runs
now continue to run with no serious loss of aesthetic appeal.
I changed the proposal and extended the rationale.
-kmp
-----
Issue: TAGBODY-CONTENTS
References: TAGBODY (pp 130-131 of CLtL)
Category: CLARIFICATION
Edit History: 13-Sep-88, version 1 by Walter van Roggen
02-Oct-88, version 2 by Pitman
(beef up rationale, clarify tag NIL is ok)
04-Oct-88, version 3 by Pitman (fix wording bug)
05-Oct-88, version 4 by Pitman
(modify proposal based on comments from Peck@Sun
-- allow both (GO NIL) and unused duplicated tags)
Problem Description:
CLtL specifies that symbols and integers are valid tags
in a TAGBODY and that lists are valid forms in a TAGBODY
but is silent about other data types.
Also, NIL is both a symbol and a list. Some implementations
might permit (GO NIL) because they treat NIL as a tag,
while others might not permit because they treat NIL as a form.
Proposal (TAGBODY-CONTENTS:FORBID-EXTENSION):
TAGBODY treats symbols (including NIL) and integers as tags,
and treats conses as forms.
It is an error if an expression in a TAGBODY is not a symbol,
an integer, or a cons. Implementations are forbidden from
extending this syntax.
It is an error to do a GO to a tag name for which the same
(i.e., EQL) tag appears more than once in the body of the
innermost TAGBODY containing that tag.
The same restrictions apply to all forms which implicitly use
TAGBODY, such as PROG and DO.
Rationale:
The proposed set of tags is expressionally adequate.
Other obvious candidate types have lurking problems that could
lead to subtle program bugs if permitted as tags. For example,
- Characters make bad tags because, for example,
(TAGBODY ... #\Return ... #\Newline ...)
will be an error in some implementations due to
(EQL #\Return #\Newline).
- Floats make bad tags because round-off error will vary
between implementations.
- Rationals have problems with reduction to lowest terms.
eg, (EQL 1/2 2/4). This doesn't vary between implementations
but may still cause surprises.
Duplicated tags are permitted in situations where no GO is done
to them primarily for two reasons:
- To permit NIL to occur more than once in common situations
such as:
(defmacro foo1 (&rest args)
`(do () ((test-fn))
,(when (member :bar args) '(do-bar-thing))
,(when (member :baz args) '(do-baz-things))
(do-regular-things)))
- To permit the use of symbols as `dividers' between major
sections of code. eg,
(do (...)
(...)
-----
(...)
(...)
-----
(...))
It is not our intent particularly to encourage either of these
practices. Both are easy to work around. But current practice is
to permit such uses in many implementations, and there was no driving
reason to force such code to break.
Current Practice:
Symbolics Genera documents that only symbols or integers are permitted.
The restriction is enforced by the compiler, but not the interpreter.
The TI Explorer permits using NIL as a GO tag, but as a special case,
does not warn about multiple appearances of NIL.
Cost to Implementors:
A few simple checks are probably all that's needed. Probably most
implementations (both interpreters and compilers) already perform them.
Cost to Users:
Unlikely to affect any portable code.
If there are implementations which support other objects as tags
(floats, for example), there may be simple editing necessary.
Benefits:
One less place for portability problems to occur.
Aesthetics:
Makes the language description more precise.
Discussion:
This first appeared in ">GLS>clarifications.text" of 12/06/85.
Historical Note (JonL, Steele):
The reason pdp10 MacLisp allowed numbers, including flonums,
as tags was that Ira Goldstein's LLOGO (a LOGO system
written entirely in Lisp) just used READ for the statement
numbers, and they looked like floats; e.g., 1.1, 1.2, ... etc.
Pitman supports this proposal.
∂05-Oct-88 2044 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 20:44:52 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 20:43:19 PDT
Date: 5 Oct 88 20:43 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: TAGBODY-CONTENTS (Version 4)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Wed, 5 Oct 88 23:30 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881005-204319-2154@Xerox>
It would be just as easy to say that if duplicate tags are present, the
first one takes precedent. I'd say that along the lines of performance,
implementation cost, readability that its a wash and that the aesthetics
are slightly improved.
∂05-Oct-88 2049 CL-Cleanup-mailer Re: Issue: TAGBODY-CONTENTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 20:49:47 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 471507; 5 Oct 88 23:48:18 EDT
Date: Wed, 5 Oct 88 23:48 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAGBODY-CONTENTS (Version 4)
To: Masinter.PA@Xerox.COM
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881005-204319-2154@Xerox>
Message-ID: <881005234808.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: 5 Oct 88 20:43 PDT
From: masinter.pa@Xerox.COM
It would be just as easy to say that if duplicate tags are present, the
first one takes precedent.
Indeed, it would be easy to say. It would be harder to feel really
comfortable that that was what the user intended and that you didn't
just have a syntax error. Just as reasonable would be to take the tag
that was visually closest, assuming the user couldn't get the whole
function on the screen to see the conflict. I'd just as soon not make
an arbitrary decision since I don't think anyone's pushing for it.
The proposal on the table is conservative on this point, which is why
I like it.
I'd say that along the lines of performance, implementation cost,
readability that its a wash and that the aesthetics are slightly improved.
By your suggestion, mine, or both?
∂05-Oct-88 2050 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 5 Oct 88 20:50:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 05 OCT 88 20:47:18 PDT
Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: Christopher.McConnell@A.GP.CS.CMU.EDU
Message-ID: <881005-204718-2157@Xerox>
I discovered that I had neglected to forward this issue, for
which I apologize.
!
Issue: PRINT-CIRCLE-STRUCTURE
References: pp. 370-371
Category: CLARIFICATION
Edit history: Version 1.0, Chris McConnell 9/20/88
Problem description:
When a print function for a structure is defined using the
:print-function option to defstruct, circular references are no longer
printed with #n# syntax even though *print-circle* is T. This
prevents printing structures that point to objects that cannot be
printed and prevents the development of new printed representations
that can be read by the reader.
Proposal PRINT-CIRCLE-STRUCTURE:
When *print-circle* is T, the printer should detect and print
circularities using the #n# syntax even if a structure has a user
defined print-function. Circularities need only be detected for
objects that would normally be printed by the default structure
print-function. A user defined print-function can print any object
that is pointed to by the structure being printed, or any object that
would normally be printed as a component of such an object and expect
circularities to be detected.
Test Cases/Examples:
;;;
;;; Define a structure that can be circular and that has a slot with a
;;; value that cannot be printed.
;;;
(defstruct (TEST (:print-function print-test))
ptr
(function #'(lambda (x)
(error "No function is defined."))))
;;;
;;; This print function generates a machine readable printed
;;; representation for a structure with a slot that cannot be printed.
;;;
(defun PRINT-TEST (structure stream depth)
(format stream "#S(TEST PTR ~A)" (test-ptr structure)))
;;;
;;; Define two structures that point to each other. If this
;;; expression successfully evaluates at the top level, then the
;;; printed result should look like:
;;; #1=#S(TEST PTR #S(TEST PTR #1#))
;;;
;;; If it does not work then it will generate an infinite printed
;;; representation.
(setf *print-circle* t
*a (make-test)
*b (make-test)
(test-ptr *a) *b
(test-ptr *b) *a)
Rationale:
Many structures are circular and point to complex data structures that
may include things like closures that cannot be printed. It should be
possible to define a way to print these data structures such that they
can be read back in. Common LISP provides two mechanisms for these
problems (*print-circle* and the :print-function option to defstruct),
but they do not currently work together.
Current practice:
None of the Common LISPs that I have worked with currently implement
this proposal. That includes Symbolics 7.2, Lucid 3.0, KCL, Coral and
Franz.
Cost to Implementors:
I believe that it is a rather straightforward change. All of the
implementations detect circularities for the default structure
printer. All that is required is to perform the same circularity
check and printing #n= before or #n# instead of what would normally be
generated by the user defined print-function.
Cost to Users: None
Cost of non-adoption:
If nothing is done, the whole effort to provide a portable printed
representation of LISP structures is of minimal usefulness. In almost
any real application, there are circular structures with non printable
objects such as closures and hash tables that need to be printed. In
addition the development of printers for new reader macros becomes
much more of an effort then it should be since it requires
reimplementing the complete circularity detection mechanism.
Benefits:
If the proposal is adopted, then it becomes easier to define new
printed representations that are compact and that still capture the
information needed to rebuild data structure instances. It allows a
printed representation to hide the actual details of how a data
structure is implemented in terms of underlying LISP data structures.
For an example see the discussion section.
Esthetics:
This proposal increases the uniformity of the language by making
*print-circle* work in all cases including where a user has defined a
new print function.
Discussion:
I first came across this problem in trying to generate a printed
representation for CLOS instances. The current PCL implementation of
CLOS implements an instance as a structure with four slots. One of
the slots points to an array that stores information about the class
that the structure is an instance of. That array points to a number
of other data structures that cache various information and that point
to other data structures some of which point to closures. If you try
to print an instance using the #S syntax, most printers will blow up
because eventually, you try to print a closure. In addition, there is
all sorts of extraneous detail that does not really belong in a
printed representation of an instance. A #I reader syntax can easily
be defined that represents a CLOS instance as a class name and a list
of slot names and values much like the #S syntax. When this is done
by defining a structure print-function, the circularity detector no
longer detects circularities. The only way to get around this is to
write your own circularity detector that works for all LISP objects.
This can be done, but it seems like a lot of effort when the exact
mechanism that is needed is already built into Common LISP.
Part of the reason for wanting to be able to do things like this is to
be able to generate files that have a compiled representation of data
structures in them. To do this, you put something like:
(setq *a '#.*a)
in a file and then you compile it in an environment where *a is bound
to the data structure you would like to save in the file. The result
is a compiled file that contains the data structure that you want. In
order for this to work, some compilers use the printer mechanism to
generate a printed form of the data structure and then compile that.
This use of the printed representation of objects could be alleviated
if there existed some mechanism equivalent to the
sys:dump-forms-to-file function provided by Symbolics.
∂05-Oct-88 2154 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 21:53:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471525; Thu 6-Oct-88 00:41:55 EDT
Date: Thu, 6 Oct 88 00:41 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
To: Christopher.McConnell@A.GP.CS.CMU.EDU, Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881005-204718-2157@Xerox>
Message-ID: <881006004144.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
Given that no one currently supports the suggested action, this
may technically be a clarification, but I think it would be better
to say CLARIFICATION/CHANGE to be clear up front about the fact
that careful reading is in order.
I would prefer if ~S was used instead of ~A in the examples.
This is not a clarification. It's
Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
...
Issue: PRINT-CIRCLE-STRUCTURE
...
Proposal PRINT-CIRCLE-STRUCTURE:
When *print-circle* is T, the printer should detect and print
circularities using the #n# syntax even if a structure has a user
defined print-function. Circularities need only be detected for
objects that would normally be printed by the default structure
print-function.
Sentences one and two are vague enough that I can't tell why they don't
contradict each other.
A user defined print-function can print any object that is pointed
to by the structure being printed, or any object that would normally
be printed as a component of such an object and expect circularities
to be detected.
This isn't adequately specific for my taste. I can sort of guess where
these restrictions are coming from, but from the point of view of the
explicitly written text here, they seem unmotivated.
...
Cost to Implementors:
I believe that it is a rather straightforward change. All of the
implementations detect circularities for the default structure
printer. All that is required is to perform the same circularity
check and printing #n= before or #n# instead of what would normally be
generated by the user defined print-function.
I don't think this is specific enough.
...
Discussion:
...
This use of the printed representation of objects could be alleviated
if there existed some mechanism equivalent to the
sys:dump-forms-to-file function provided by Symbolics.
This is in a throwaway position in the document. If it's really true
that this is an alternative in general (which I'm not sure I believe),
then I don't think this proposal has given me an adequate survey of
the issues and options.
Overall I'm sympathetic to the issue but not (yet) to the proposal.
There's something kind of vague and hand-wavey about the writeup that
doesn't make me feel like I know exactly what I'm signing up for or why.
It's entirely possible that a tighter rewrite of the same idea would fix
things, though. At this point, I don't have any sense of a fundamental
objection looming in the wings.
∂05-Oct-88 2312 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 23:12:15 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471537; Thu 6-Oct-88 02:10:54 EDT
Date: Thu, 6 Oct 88 02:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: EVAL-OTHER (Version 2)
To: miller@CS.Rochester.EDU
cc: Common-Lisp-Object-System@SAIL.Stanford.EDU,
CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881006022307.0.MILLER@DOUGHNUT.CS.ROCHESTER.EDU>
Message-ID: <881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Wed, 5 Oct 88 22:23 EDT
From: Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>
... I would suggest that the DEFSTRUCT (or DEFFLAVOR) have an option that
explicitly specifies the eval behavior. ...
The problem to this is that it's the same as allowing fexprs. This is
something we've worked hard to eliminate from CL because it is opaque
to compilation.
You could argue that MACROEXPAND-1 should be a generic function I suppose.
I have no strong feeling on that subject right now, but I'm biased against
it because we are very close to casting this stuff in concrete and I don't
feel totally comfortable that I understand the consequences of doing so.
One minor procedural matter: You're more likely to get this considered if
you write up the proposal in full rather than just as a little fragment.
I count 194 cleanup topics that have been raised, and it's getting harder
and harder to `maintain' them. Some are destined to fall through the cracks
for lack of time and anything that people have a minor bias against can be
very easily pocket-veto'd if it doesn't come in in a form that we can
directly vote on...
∂05-Oct-88 2330 CL-Cleanup-mailer Issue: FORMAT-PRETTY-PRINT (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 5 Oct 88 23:29:59 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471546; Thu 6-Oct-88 02:28:07 EDT
Date: Thu, 6 Oct 88 02:27 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FORMAT-PRETTY-PRINT (version 5)
To: Masinter.PA@Xerox.COM, pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881002-133141-2667@Xerox>
Message-ID: <881006022755.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I expect to eventually support this proposal, but would like to see a
couple of issues dealt with first...
Date: 2 Oct 88 13:31 PDT
From: masinter.pa@Xerox.COM
...
Issue: FORMAT-PRETTY-PRINT
...
Proposal (FORMAT-PRETTY-PRINT:YES):
Specify that FORMAT does rebind any of the printer control
variables (*PRINT-...) except as follows:
I assume you mean "...does not rebind..."
~R
Binds *PRINT-ESCAPE* to NIL, *PRINT-RADIX* to NIL, and
*PRINT-BASE* to the value of the first argument iff a first
argument is specified.
I'd say: ``Iff a first argument is specified, binds *PRINT-ESCAPE*
to NIL, *PRINT-RADIX* to NIL, and *PRINT-BASE* to the
value of the first argument.''
It doesn't really matter what happens if there is no argument, but
this would avoid any silly questions on the subject.
Actually: CLtL doesn't say the English ordinal is base-10. One
could imagine expecting that someone might want
(LET ((*PRINT-BASE* 8)) (FORMAT NIL "~R" 8))
=> "ten"
Presumably this is not what anyone does, but perhaps we should
shoe-horn that in here (to avoid writing up a whole issue for such
a silly little detail). ... Or perhaps we should say that in the no
argument case it binds *PRINT-BASE* to 10, and let people infer from
that that it's insensitive to bindings of *PRINT-BASE* in the
no-argument case.
~F,~G,~E,~$
Binds *PRINT-ESCAPE* to NIL.
Again, one might expect that
(LET ((*PRINT-BASE* 8)) (FORMAT NIL "~E" 8.5))
should return "10.4". Maybe we should say that *PRINT-BASE* is
bound to 10, etc. just to avoid this issue?
Test Cases/Examples:
...
The test case is very cute but overly complicated and doesn't
address the full scope of the proposal.
∂06-Oct-88 0019 CL-Cleanup-mailer Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 00:19:40 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471553; Thu 6-Oct-88 03:16:48 EDT
Date: Thu, 6 Oct 88 03:16 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LIST-TYPE-SPECIFIER (Version 1)
To: Beckerle@XX.LCS.MIT.EDU, Masinter.PA@Xerox.COM
cc: eb@Lucid.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <12426886415.53.BECKERLE@XX.LCS.MIT.EDU>,
<8809172344.AA00896@blacksox>
Message-ID: <881006031630.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
Count me as wanting the LIST type specifier to treat its arguments like
the ARRAY type specifier.
Although it's true the ARRAY type specifier is a mess, it would only
be emphasized by something so syntactically similar as this behaving so
radically differently.
Strange as it sounds, I might be susceptible to a proposal for (LIST-OF
FIXNUM FLOAT) to mean what (LIST FIXNUM FLOAT) is proposed to mean and
vice versa. I don't think there's anything about LIST-OF which really
forces the suggested interpretation. That way, the same functionality
would be available and things would be more consistent. ... or maybe
LIST-CONTAINING.
If this feature of enumerated types is going to be added for lists, though,
perhaps it would be useful for vectors and arrays, too. Just as we can
specify array values using #(...) and #A notation, maybe we should be able
to type them that way as well. There are two possible approaches:
(LIST-CONTAINING (FIXNUM FLOAT))
(VECTOR-CONTAINING (FIXNUM SYMBOL))
(ARRAY-CONTAINING ((FIXNUM FLOAT) (T SYMBOL)))
or
(CONTAINER (FIXNUM FLOAT))
(CONTAINER #(FIXNUM SYMBOL))
(CONTAINER #2A((FIXNUM FLOAT) (T SYMBOL)))
Unfortunately, this whole topic is so hard to think about, I don't claim
I can keep it all in my head. I might have other criticisms if I saw a
proposal drafted that way ... but I'd think we were making progress.
∂06-Oct-88 0114 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 01:14:36 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471568; Thu 6-Oct-88 04:13:04 EDT
Date: Thu, 6 Oct 88 04:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (Version 4)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881006041254.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
I have some (mostly non-technical) wording gripes which I think should
be made for clarity...
- Don't refer to uppercase being "normally used". It depends on
the application, etc. Just refer the user to INTERN.
- Don't refer to "inheriting" in the description of :USE.
Refer to USE-PACKAGE. Similarly, :SHADOW should refer to
SHADOW, etc. After all, we've gone to considerable trouble
to explain each of these concepts and we can't afford to have
some bit of vague wording accidentally bind us into an
inconsistency here. It is easier and more correct to simply
say exactly what primitive these are giving us access to.
- Rather than say what happens last,etc just say these will happen
in an order that makes it all work if it's possible to make work.
One of the major flaws of the ``put in seven...'' slogan is that
it is not always possible to win that way -- it's only a rule of
thumb and sometimes you have to use another ordering. DEFPACKAGE
should be capable of constructing a correct ordering regardless
of what order the user uses.
- It's hard to tell if the comment in the examples is intended as
general advice to people about how they should use DEFPACKAGE
or a comment about what's going on in this particular DEFPACKAGE.
It's obvious once you see the next test, but I think some fixing
up should be done to avoid initial confusion. In fact, I might
invert the order of the examples.
- Also, I'd show the examples in lower case (with uppercase strings,
of course) to emphasize the uppercasing feature of symbols that
people seem so hooked on. Also, that would make it clear (by
contrast) that the case of strings had to be uppercase and was
not just accidentally matching the surrounding code.
- I'm not a big fan of permitting the package name itself (the
cadr of the DEFPACKAGE form) to be a string. That interacts badly
with our editor (and many others I know of). But maybe that just
means we should fix our editor. I dunno. I'd prefer people just
put the package name in the keyword package.
- In the Discussion, the remark about "The macroexpansion of
DEFPACKAGE should be permitted to canonicalize into the ..."
appears to belong elsewhere in the proposal. If it's `just an
idea,' and not intended as part of the proposal, it should say
so very clearly.
Ditto for "Additional options might be present..."
and "Frequently additional implementation-dependent..."
∂06-Oct-88 0125 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 01:25:26 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 396198; Thu 6-Oct-88 03:47:16 EDT
Date: Thu, 6 Oct 88 03:44 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881005-005724-4531@Xerox>
Message-ID: <881006034426.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Ok, so I finally got caught up in my reading on this. This is starting
to look pretty good, but I've bot a bunch of picky little comments about
how this should be projected ...
Date: 5 Oct 88 00:57 PDT
From: masinter.pa@Xerox.COM
...
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
...
in most implementations of CL, an array X created with and element-type
"an element-type" ?
...
This proposal suggests elimination of this distinction for the array types
ARRAY, SIMPLE-ARRAY, and VECTOR and their subtypes, by guaranteeing that
arrays constructed with a specific element-type satisfy the typep predicate
with the derived array type-specifier, and by guaranteeing that subtypep
reflect the type equivalences defined by the behavior of make-array.
This paragraph doesn't belong in the problem description!
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
-- Introduce a function, UPGRADE-ARRAY-ELEMENT-TYPE of one argument, which
reveals how the given implementation treats a particular :element-type
argument to make-array. Given a type-specifier <type1> as argument, it
returns a maximal type-specifier <type2> such that <type2> is the
actual specialized array element type used whenever <type1> is given as
an :element-type argument to MAKE-ARRAY. Note that
(upgrade-array-element-type '<type>) =
(array-element-type (make-array 0 :element-type '<type>))
for all type specifiers <type>.
I haven't decided how I feel about this part. You could do the same by
just saying ``Introduce the concept of an `upgraded' array-element-type...''
without actually providing the function that does the upgrading. But I guess
I think providing the function is harmless. Presumably it will be there anyway.
...
Test cases:
...
Thus, in each case, it should be true that:
I'd say "will happen to be true that", and emphasize that it's important
to know that this might happen -- but it's not something that should be
particularly depended upon since obviously it will vary across implementations.
...
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
This is a feature and should be encouraged.
(subtypep '(array <aet-y>) '(array <aet-x>))
This happens by accident and might not always happen. Again, document it, but
make sure it's clear that this is only something to `guard against' and not
something to generally depend upon.
Additionally, to show that un-equivalent type-specifiers that are upgraded
to
the same "element type" should be equivalent as element-type specifiers,
the
following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
Accidental,etc.
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Intentional,etc.
∂06-Oct-88 0132 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 01:32:52 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 471580; 6 Oct 88 04:31:24 EDT
Date: Thu, 6 Oct 88 04:31 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-CLUTTER (Version 3)
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880923-011503-3968@Xerox>
Message-ID: <881006043113.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
A few comments...
Date: 5 Oct 88 14:08 PDT
From: masinter.pa@Xerox.COM
...
Issue: PACKAGE-CLUTTER
...
Proposal (PACKAGE-CLUTTER:REDUCE):
...
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be functions or macros,
Don't you mean "variables"?
...
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available.
I'm not sure I agree with doing this. The purpose of "SYSTEM" is not so
users can rely on it, but rather so they'll know what -not- to use.
Since some systems have other packages locked up as well, maybe that's
a weak argument. Maybe your package registry is the only way to go...
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Why not say "USER" is empty but uses other packages, including
implementation-specific ones? I don't see any reason why that couldn't
be trivially made to be true.
Examples:
...
#2: Since it is not defined as a variable, type, or function, however,
it may not be bound, defined as a type, or defined as a function,
macro or special form.
"may not be initially bound, ..." would make this consistent with your
desire not to trample on LISP-SYMBOL-REDEFINITION.
∂06-Oct-88 0207 CL-Cleanup-mailer Issue: PROCLAIM-LEXICAL (Version 8)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 02:07:43 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471589; Thu 6-Oct-88 05:06:10 EDT
Date: Thu, 6 Oct 88 05:05 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PROCLAIM-LEXICAL (Version 8)
To: Masinter.PA@Xerox.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881006050558.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Per your request, here's a new version merging recent discussion.
I don't think this is in a form where it's ready to be voted on, but
maybe it's suitable for X3J13 to be reading over and thinking about
while we work on banging out the details that are up in the air.
-----
Issue: PROCLAIM-LEXICAL
References: variables (p55), scope/extent (p37), global variables (p68),
declaration specifiers (p157)
Category: CLARIFICATION/ADDITION
Edit history: Version 2 by Rees 28-Apr-87
Version 3 by Moon 16-May-87
Version 4 by Masinter 27-Oct-87
Version 5 by Masinter 14-Nov-87
Version 6 by Pitman 15-Sep-88
(major revision, for review by Jonathan Rees and Jeff Dalton)
Version 7 by Pitman 24-Sep-88
(minor revisions based on comments from Rees and Dalton)
Version 8 by Pitman 06-Oct-88 (merge recent discussion)
Status: For Internal Discussion
Problem Description:
Although local variables in Common Lisp may be `special' or `lexical,'
global variables (with the exception of named constants) may currently
only be `special.'
The Scheme language permits free variable references to refer to global
bindings. Their experience suggests that such usage would be useful to
the Common Lisp community. The absence of such a facility in Common Lisp
is a barrier both culturally (to the sharing of ideas) and technically
(to the sharing of code).
SPECIAL proclamations are uncontrollably pervasive. There is no way
to locally override or globally undo a SPECIAL proclamation.
Background/Analysis:
Variable evaluation may be viewed in Common Lisp as a search through
a set of environments to find a binding, and then the dereferencing of
that binding. The environments with which Common Lisp deals are
Lexical (L), Dynamic (D), and Global (G).
A SPECIAL declaration for a variable amounts to a request that the
variable be resolved by searching first the Dynamic and then the Global
environment (DG).
As currently described in CLtL, lexical variable reference searches
only the Lexical environment (L).
Because undeclared free variables in the interpreter are implicitly
declared SPECIAL by most (perhaps all) implementations, this amounts
to a search of Lexical, Dynamic, and Global (LDG). However, the
accompanying warnings in many implementations make it clear that this
behavior is not intended to be taken seriously.
Constants are looked up solely in the Global environment (G). They
have other properties as well, of course.
In the Scheme language, the default lookup is first Lexical, then
Global (LG). Providing compatibility for Scheme code is, and more
generally for a Scheme working style is therefore difficult because
Common Lisp does not provide the LG search style.
The issue of whether a variable can be assigned is orthogonal.
The issue of whether a variable can be bound and, if it can be, which
environment is used for the new binding is orthogonal.
Proposal (PROCLAIM-LEXICAL:LG):
Provide a new declaration (and proclamation) called LEXICAL which does
LG lookup. That is, variables declared LEXICAL would be looked up first
in the lexical environment (L) and then in the global environment (G)
if not found in the lexical.
Clarify that dynamic binding does DG lookup. That is, variables
declared SPECIAL would be looked up first in the dynamic
environment (D) and then in the global environment (G) if not found
in the lexical. Further clarify that SYMBOL-VALUE does DG lookup.
Define that a dynamic binding of a variable creates a new binding
in the dynamic environment (D) leaving the global environment (G)
unaffected.
Define that a lexical binding of a variable creates a new binding
in the lexical environment (L), leaving the global environment (G)
unaffected.
Note that an assignment to a variable which is bound in the global
environment (G) will affect lexical (LG) lookups for which there is
no lexical (L) binding and dynamic (DG) lookups for which there is
no dynamic (D) binding.
Note that these restrictions describe an abstract model, not a
concrete implementation. An implementation may still choose to
implement dynamic binding as either deep or shallow, but some
searching may be necessary to find the global cell in shallow bound
implementations [unless dynamic binding has been forbidden for
that variable].
Like SPECIAL declarations (and unlike type declarations),
compilers and interpreters would be required to notice and
respect this declaration.
Test Case:
#1: (proclaim '(lexical x))
(setq x 1)
(defun f (fn) (list x (funcall fn)))
(defun g (fn)
(let ((x 2))
(declare (special x))
(funcall fn #'(lambda () x))))
(g #'f) => (1 2)
#2: ; Warning: It is unlikely that any serious program would
; be written in so obscure a manner as this example.
; This just tests the fringe cases.
(proclaim '(lexical x))
(proclaim '(special y))
(setq x 1 y 2)
(defun tst ()
(let ((x 3) (y 4))
(locally (declare (special x) (lexical y))
(list x y
(funcall (let ((x 5) (y 6))
#'(lambda () (list x y))))))))
(tst) => (1 2 (5 4))
If the results of this example confuse you, keep in mind
that the results of code like this would be somewhat
confusing no matter what the chosen semantics because the
code itself is far from perspicuous.
An explanation of this behavior, which some people find less
than intuitive because of the bizarre choice of constructs:
X gets bound lexically to 3 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 4 because Y is [pervasively]
proclaimed SPECIAL.
Reference style for name X is changed to SPECIAL, making
lexical X=3 invisible.
Reference style for name Y is changed to LEXICAL, making
dynamic Y=4 invisible.
Global X=1 and global Y=2 are first two elements of list.
X gets bound lexically to 5 because X is [pervasively]
proclaimed LEXICAL.
Y gets bound specially to 6 because Y is [pervasively]
proclaimed SPECIAL.
Closure is returned, capturing [lexical] X=5 but not
[special] Y=6.
Dynamic binding of Y to 6 disappears, dynamic binding
of Y to 4 reverts.
Closure is funcalled, returning captured X=5 and dynamically
active Y=4 in a list which becomes third list element.
Rationale:
This mechanism provides a simple and straightforward answer to
the problems stated above.
Current Practice:
Probably no one implements this.
Cost to Implementors:
A fair amount compiler work would probably be needed. Some compilers
may have hooks for most of this already laying around, but some may not.
Note well that this proposal does not require separate global lexical
and dynamic cells, so the data storage layout of Lisp need not change.
Moon says...
I have now thought of an efficient way to do this on Lisp machines,
using invisible pointers, and another efficient way to do it on
stock hardware, using one extra instruction on every global
reference of one or the other sort, plus a few extra instructions
in SPECIAL binding and unbinding. Given that, I no longer object
to the proposal as unimplementable.
It doesn't just require a few compiler changes, it requires some
reimplementation of the representation of global variables, with
concomitant changes to the compiler, the loader, the interpreter,
and probably the debugger. Every symbol now potentially has two
values accessible from the interpreter (the current SPECIAL and
the global LEXICAL) and you need the corresponding new data
structure to keep track of that.
Rees suggests...
In shallow-bound implementations, implementors may have to add a
small run-time routine that searches the dynamic saved-binding
stack to look for the global value in the case where the variable
has been dynamically bound. One might want a bit (or a count)
somewhere (perhaps in the symbol itself) to speed up the common
case of access to a global binding of a variable that hasn't been
dynamically bound; without some kind of optimization, you have to
search the whole saved-binding stack on every reference to a
free [lexical] variable.
While naively you might think you'd incur the cost of clearing the
valid bit on every dynamic binding (not acceptable), in actuality
the bit is a static property of programs (PROGV excepted). So the
only places you ever need to clear FOO's valid bit are in PROGV,
in the interpreter, and when FASLOADing code that contains a compiled
dynamic binding of FOO.
Cost to Users:
For the most part, this change is upward compatible.
Some code-walking tools would have to change.
Cost of Non-Adoption:
It would continue to be difficult to share code with Scheme.
New CL users coming from the Scheme community would be confused by
their sometimes inability to map what they know about variable binding
into the CL model of variable binding.
Some interesting native CL applications would be impossible to write
in a syntactically convenient style.
Benefits:
Enhanced flexibility of expression.
Rationalization of the semantics of dynamic variables.
Aesthetics:
Improved appeal to a certain sector of the programming community.
Discussion:
Rees points that it is an oversimplification to describe Scheme's
binding simply as LG since they have no Dynamic environment and
there is no way to distinguish LG and LDG. However, the reasons he
prefers LG are:
1. It's nice for readability and understandability to have a
declaration which tells you that a variable will not be
dynamically bound.
2. It's nice for performance in deep-bound implementations to have a
declaration that says that no search will be needed.
Of course, he notes, there could be a counter-argument to item 2
(in favor of LDG) in order to prefer shallow bound implementations,
but that still would not defeat the argument in item 1. Rees believes
that LG is slightly preferrable, but that LDG would be essentially
adequate for most of his needs.
Pitman supports PROCLAIM-LEXICAL:LG and believes that giving LDG the
name LEXICAL would be a serious mistake, leaving open the door for
program bugs due to accidental binding of variables presumed by the
programmer not to be bound. If someone (Moon?) seriously wanted LDG
type variables in addition to LG variables (under a name other than
LEXICAL), Pitman would not object.
Dalton expressed support for PROCLAIM-LEXICAL:LG (Version 6).
He observes that another reason for opposing LDG is that it suggests
the possibility that someone might want DLG. LG is simpler and still
accomplishes the stated purpose. He adds ``I would like to be able
to explain the global environment as a sort of giant, extensible
LET abound everything. This proposal seems to get fairly close.''
It would be possible to submit a proposal for a GLOBAL (G) declaration
under separate cover if anyone (Xerox?) was interested. Pitman thinks
this would be an interesting idea. Dalton points out, however, that
already with this proposal there is enough power to at least deal with
globals -- albeit circuitously. For example, to reference a global
variable X, one could write subroutines such as:
(defun global-x () (declare (lexical x)) x)
(defun set-global-x (value) (declare (lexical x)) (setq x value))
Eg, consider:
(defun f (x) (+ (global-x) x))
In principle, we could imaging saying that free variables should be
lexical by default, but that would only reduce error checking to no
good end. To be really useful, this proposal will need to be followed
by a proposal for primitives analogous to DEFVAR and/or DEFPARAMETER
but for lexical variables. However, since arguments over syntax are
likely to have plenty of issues of their own, we've separated this
proposal for primitive functionality from issues of syntax which
can be dealt with separately once this is passed.
Moon expressed concerns about the efficiency issues but after
thinking about it for a while convinced himself that this is
efficiently implementable both on stock and special purpose hardware.
JonL expressed concerns about the last-minute nature of this change,
which he sees as untested.
Dalton suggests that an alternative solution to the speed issue
might be possible to obtain by restricting a particular variable to
be either LEXICAL or SPECIAL but not both.
Dalton points that even if people don't like the details here, there
must be a better fallback solution than "do nothing". Pitman agrees
heartily.
∂06-Oct-88 0827 CL-Cleanup-mailer Re: Issue: FUNCTION-COMPOSITION (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 08:27:40 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 6 Oct 88 11:24:31 EDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: Issue: FUNCTION-COMPOSITION (Version 1)
In-reply-to: Your message of 02 Oct 88 14:32:00 -0700.
<881002-143242-2709@Xerox>
Date: Thu, 06 Oct 88 11:24:02 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
How do you feel about removing :TEST-NOT and -IF-NOT?
This would break a lot of existing user code for merely cosmetic gain. I
have no objection to deprecating these options and providing something more
elegant, but I wouldn't like to see them tossed out. I could think of
several hundred things that are equally ugly...
-- Scott
∂06-Oct-88 1019 CL-Cleanup-mailer several hundred ugly things
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 10:19:45 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 10:10:28 PDT
Date: 6 Oct 88 10:09 PDT
From: masinter.pa@Xerox.COM
Subject: several hundred ugly things
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 06 Oct 88
11:24:02 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Message-ID: <881006-101028-2851@Xerox>
Scott:
There's some desire in some parts of ISO to make Common Lisp "smaller". I'd
just as soon see it done carefully -- rather than with an axe. If you can
think of several hundred things that could be done to Common Lisp that
would make it smaller and not as ugly, perhaps you could help name a few?
Maybe this isn't the time to do these things -- maybe these changes don't
belong in the 1989 draft standard -- but it would be helpful to at least
have on hand a list of possibilities for the future.
Yes, lets get this standard out and out of the way. But eventually the
draft should include some indication of future directions. That's why
people are starting to talk about deprication and the like now -- because
we can start to see the end.
∂06-Oct-88 1034 Common-Lisp-Object-System-mailer Re: Issue: EVAL-OTHER (Version 2)
Received: from hplms2.hpl.hp.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 10:34:39 PDT
Received: from hplwhh.HPL.HP.COM (hplwhh.hpl.hp.com) by hplms2.hp.com; Thu, 6 Oct 88 10:30:30 pdt
Received: from loopback by hplwhh.HPL.HP.COM; Thu, 6 Oct 88 10:30:06 pdt
Full-Name: Warren Harris
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
miller@CS.Rochester.EDU
Cc: Common-Lisp-Object-System@SAIL.Stanford.EDU, CL-Cleanup@SAIL.Stanford.EDU
Subject: Re: Issue: EVAL-OTHER (Version 2)
In-Reply-To: Your message of "Thu, 06 Oct 88 02:10:00 EDT."
<881006021043.8.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 06 Oct 88 10:30:02 PDT
Message-Id: <8592.592162202@hplwhh>
From: Warren Harris <harris%hplwhh@hplabs.hp.com>
I don't know about making EVAL a generic function due to the ramifications
this has on the compiler, but there are several other places in CL in which
functions should be required to be generic.
One example might be in the equality area. Common Lisp seems to have a
wealth of equality predicates, EQ, EQL, EQUAL, EQUALP, =, STRING=, CHAR=
... and you kind of pick and choose based on what you know about the
application. It would be nice to have at least one version of equality
which did the right thing based on what it was comparing. Perhaps this is
EQUALP. EQUALP already looks inside both cons cells and arrays, why not
extend it to look inside objects too. I suggest the following definition
of EQUALP:
(defmethod equalp ((x t) (y t))
(eq x y))
(defmethod equalp ((x character) (y character))
(char-equal x y))
(defmethod equalp ((x number) (y number))
(= x y))
(defmethod equalp ((x cons) (y cons))
(or (eq x y)
(and (equalp (car x) (car y))
(equalp (cdr x) (cdr y)))))
(defmethod equalp ((x object) (y object))
(let ((cx (class-of x))
(cy (class-of y)))
(or (eq x y)
(and (eq cx cy)
(every #'(lambda (slotd)
(let ((name (slotd-name slotd)))
(equalp (slot-value-using-class cx
x
name)
(slot-value-using-class cx
y
name))))
(class-slots cx))))))
(defmethod equalp ((x array) (y array))
...)
COERCE is another good candidate for being made generic. Like the print
system which is required to go through the PRINT-OBJECT method, COERCE
could ultimately invoke a generic layer:
(defun coerce (thing type)
(case type
<old coerce code ...>
(t
(coerce-object thing (find-class type)))))
(defmethod coerce-object ((thing t) (c class))
(error "~S cannot be coerced to type ~S."
thing (class-name c)))
This would allow the user to write class specific coercion routines. One
objection has been raised to this proposal by Moon:
> But it's meaningful for COERCE's second argument to be a type specifier that
> does not name a class. CLtL gives as an example (vector (complex short-float)).
> It would be inconsistent to do some coercions with classes and others through
> some other mechanism. I don't think your idea will work without a larger
> recasting of Common Lisp in object-oriented terms. While that's an interesting
> project for investigation, I suspect it would quickly go way beyond the
> proper charter of a standardization effort.
I think the above code demonstrates how this can indeed work given CL's
non-class type specifiers. COERCE itself is not required to be generic, it
is simplied required to ultimately call COERCE-OBJECT. This is exactly the
requirement placed on PRINT.
> One minor procedural matter: You're more likely to get this considered if
> you write up the proposal in full rather than just as a little fragment.
How do I do this? How does it look, and who do I send it to?
Warren Harris
HP Labs
∂06-Oct-88 1213 CL-Cleanup-mailer Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:13:32 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 471951; Thu 6-Oct-88 15:11:17 EDT
Date: Thu, 6 Oct 88 15:11 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (version 2)
To: vanroggen%aitg.DEC@decwrl.dec.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809131523.AA28994@decwrl.dec.com>
Message-ID: <881006151106.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Is it the case that this proposal makes no statement on the issue of
what happens if you do multiple proclamations for the same function?
I don't think you can completely ignore the issue because
(FUNCTION (FIXNUM FIXNUM) CONS)
is a proper global declaration for CONS if multiple declarations are
permitted, but not if only one declaration is permitted.
Am I confused?
∂06-Oct-88 1237 CL-Cleanup-mailer Issue: TEST-NOT-IF-NOT (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:37:07 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00451g; Thu, 6 Oct 88 12:34:57 PDT
Received: by bhopal id AA05405g; Thu, 6 Oct 88 12:33:16 PDT
Date: Thu, 6 Oct 88 12:33:16 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810061933.AA05405@bhopal>
To: gls@Think.COM
Cc: KMP@stony-brook.scrc.symbolics.com, CL-Cleanup@sail.stanford.edu
In-Reply-To: gls@Think.COM's message of Wed, 5 Oct 88 10:26:46 EDT <8810051426.AA26682@joplin.think.com>
Subject: Issue: TEST-NOT-IF-NOT (Version 1)
My only complaint about this is that I use REMOVE-IF-NOT much more
frequently than REMOVE-IF.
--Guy
Maybe we should add KEEP-IF :-)
I could even get serious if we called it ABSTRACT.
jlm
∂06-Oct-88 1258 CL-Cleanup-mailer Re: Issue: PRINT-PRETTY-HOOK (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 12:58:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472014; Thu 6-Oct-88 15:56:09 EDT
Date: Thu, 6 Oct 88 15:55 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: PRINT-PRETTY-HOOK (version 1)
To: Dan L. Pierson <pierson%mist@MULTIMAX.ARPA>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810041357.AA26956@mist.UUCP>
Message-ID: <19881006195542.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 04 Oct 88 09:57:34 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
I don't think you answered my question. Do you want to change the
effect of -all- calls to WRITE, PRINT, FORMAT ~S, etc.? Or do you
want to only change the printing by interactive tools (you mentioned
the read-eval-print loop, the debugger, and trace)?
Sorry, I want to change the effect of -all- calls. The only reason
that I harp on the interactive tools is that they are frequently the
hardest to change. If my own code wants to avoid the this feature I
can easily disable it locally.
Okay.
It sounds to me like what you want is a function you can redefine
(or equivalently a variable you can SETQ to a function) together
with a specification of in what situations the function will be
called.
Right, though dynamic binding would be more convenient than setting in
some cases such as local disabling.
You can get the effect of dynamic binding by globally redefining it to a
function that looks at a dynamically bound variable that tells it what to do.
Once that's clear a name can be chosen. Possibly the
feature already exists in the language, via a :AROUND method
on PRINT-OBJECT with no specialized parameters, depending on whether
what that does is precisely what you wanted.
Does it do what I want (I'm not yet a CLOS theologian)?
Yes.
I think this means we can withdraw the PRINT-PRETTY-HOOK proposal, since
Common Lisp as amended by CLOS already will do what you want.
∂06-Oct-88 1302 CL-Cleanup-mailer Issue: TAGBODY-CONTENTS (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:02:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472019; Thu 6-Oct-88 16:00:36 EDT
Date: Thu, 6 Oct 88 16:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: TAGBODY-CONTENTS (Version 4)
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881005233028.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881006200018.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
TAGBODY-CONTENTS:FORBID-EXTENSION is fine.
I hope it's clear enough that it is -not- an error to have
duplicate tags in a TAGBODY if no one goes to them. This is
implied but not stated explicitly within the body of the proposal.
∂06-Oct-88 1315 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:15:24 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00485g; Thu, 6 Oct 88 13:14:16 PDT
Received: by bhopal id AA05594g; Thu, 6 Oct 88 13:12:35 PDT
Date: Thu, 6 Oct 88 13:12:35 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810062012.AA05594@bhopal>
To: masinter.pa@Xerox.COM
Cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 5 Oct 88 14:13 PDT <881005-141417-1355@Xerox>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
"I'd like someone to
point out why you can't simply require
(equal (array-element-type (make-array n :element-type x))
x)
for all legal types x."
a) nobody does it
I believe there is precedent for correcting buggy behavior, even when
it is shared by all implementations.
Why is it so important to force to the user to be concerned with the
underlying implementation of arrays? Why are we so unwilling to
let an array remember that, e.g., its elements all satisfy PRIMEP?
I can't see any logical reason. Is there some historical reason, or
have we arrived at the current state entirely by accident?
b) its not very useful
I disagree. It makes the language easier to document and understand,
removes a source of obscure bugs, and increases portability. What
more do you want?
I thought this was in the discussion section, but it seems to be hidden.
jlm
∂06-Oct-88 1343 CL-Cleanup-mailer Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:42:54 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 13:38:20 PDT
Date: 6 Oct 88 13:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
In-reply-to: Jim McDonald <jlm@lucid.com>'s message of Thu, 6 Oct 88
13:12:35 PDT
To: Jim McDonald <jlm@lucid.com>
cc: masinter.pa@Xerox.COM, cl-cleanup@sail.stanford.edu
Message-ID: <881006-133820-1336@Xerox>
Sorry that I was so terse. Call the proposal to make arrays remember their
element types REMEMBER-TYPE.
I had also proposed REMEMBER-TYPE at one time.
This is certainly legal in current Common Lisp -- any implementation could
currently do this and conform to CLtL. However, none do. The weight of
current practice is a useful indication of the well-considered thoughts of
the designers of current implementations; in several areas, implementations
have chosen to diverge from CLtL, exactly because CLtL is "buggy". So, the
justifcation that "nobody does it" is that there is evidence that no Common
Lisp implementor so far has thought that it would be useful, consistent,
cleaner.
Secondly, there is no simple canonicalization for type specifiers.
Currently, I can reasonably expect that
(equal (array-element-type (make-array n :element-type '(integer -129
128)))
(array-element-type (make-array n :element-type '(signed-byte 8))))
yet your proposal to require that (equal (array-element-type (make-array
n :element-type x))
x)
for all legal types x."
would violate that.
It was argued that array element types are an important part of the
underlying implementation, their visibility in a portable way is useful.
It was argued that REMEMBER-TYPE would add an additional storage burden
that would be a cumbersome implementation burden.
REMEMBER-TYPE would make the language easier to document and understand
only if there were some reasonable way to handle the canonicalization of
types mentioned above.
I'm having trouble with the issues of "obscure bugs" and "increases
portability". Perhaps I'm too close to the subject, but could you supply
some examples of obscure bugs or non-portable programs which REMEMBER-TYPE
would address?
∂06-Oct-88 1350 CL-Cleanup-mailer Issue: RETURN-VALUES-UNSPECIFIED (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 13:50:42 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 13:49:05 PDT
Date: 6 Oct 88 13:49 PDT
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: RETURN-VALUES-UNSPECIFIED (Version 3)
Message-ID: <881006-134905-1353@Xerox>
I had agreed with GLS. So I changed the discussion. (Depersonalized it,
too.)
!
Issue: RETURN-VALUES-UNSPECIFIED
References: CLOSE (p 332), IN-PACKAGE (p 183), RENAME-PACKAGE (p 184),
TRACE (p 440), UNTRACE (p 440), INSPECT (p 442),
SET-SYNTAX-FROM-CHAR (p 361),
LOCALLY (p 156), PROVIDE (p 188), REQUIRE (P 188)
Category: CLARIFICATION
Edit history: 26-Aug-88, Version 1 by Chapman
19-Sept-88, Version 2 by Chapman
6-Oct-88, Version 3 by Masinter
Problem Description:
The descriptions of CLOSE, IN-PACKAGE, RENAME-PACKAGE, TRACE, UNTRACE,
INSPECT, SET-SYNTAX-FROM-CHAR, LOCALLY, PROVIDE, and REQUIRE
are not clear about the values returned from those constructs.
Proposal (RETURN-VALUES-UNSPECIFIED:SPECIFY)
Clarify that the return values for the listed constructs are as follows:
CLOSE -- the stream argument.
IN-PACKAGE -- the new package, i.e. the value of *PACKAGE* after the
execution
of IN-PACKAGE.
RENAME-PACKAGE -- the renamed package.
TRACE (when called with arguments) -- implementation-dependent.
UNTRACE -- implementation-dependent.
INSPECT -- implementation-dependent.
SET-SYNTAX-FROM-CHAR -- T
LOCALLY -- the return values of the last form of its body, i.e. the body is
surrounded by an implicit PROGN.
PROVIDE -- implementation-dependent.
REQUIRE -- implementation-dependent.
Rationale:
This clarification allows users to know when they can and can not
count on the values returned from
these constructs.
Current Practice:
Adoption Cost:
Benefits:
This clarification will assist users in writing portable code.
Conversion Cost:
Aesthetics:
None.
Discussion:
PROVIDE and REQUIRE are not likely to appear except in the "top level" of
files, and so their return value is possibly moot. There is also some
sentiment for leaving unspecified the values of the debugging/environment
features such as TRACE and UNTRACE, to allow for experimentation and
growth.
∂06-Oct-88 1530 CL-Cleanup-mailer Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 15:29:55 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472169; Thu 6-Oct-88 18:28:27 EDT
Date: Thu, 6 Oct 88 18:28 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881006182817.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
I feel we didn't give the MODIFIED variation of this proposal a fair
shake. We took GENERALIZED to X3J13 even knowing that it was the
most controversial of the two options we had. X3J13 voted it down,
not surprisingly to me. MODIFIED is considerably more conservative
and deserves consideration as a fall-back position.
-kmp
-----
Issue: SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS
References: Sequences (pp245-261), COERCE (p51)
Category: ENHANCEMENT
Edit history: 05-Feb-87, Version 1 by Touretzky (option GENERALIZED)
28-Apr-87, Version 2 by Pitman (add option MODIFIED)
26-Oct-87, Version 3 by Masinter (remove MODIFIED)
11-Nov-87, Version 4 by Masinter (respond to comments)
05-Feb-88, Version 5 by Masinter
06-Oct-88, Version 6 by Pitman
(revert to version 2, flush GENERALIZED option
-- which was rejected by X3J13 -- and resurrect MODIFIED)
Status: For Internal Discussion
Description:
Common Lisp provides many useful operations on lists and vectors which
don't apply to arrays.
For example, one can FILL a vector with 0's, but not an array. One can
REPLACE the contents of one vector with another, but one can't do this
for arrays. One can verify that EVERY element of a vector has some
property, but one can't do this for arrays. And so on.
The programmer who wishes to use arrays instead of vectors must give up
most of the useful tools CLtL provides for manipulating sequences, even
though there is no intuitive reason why operations like FILL, REPLACE,
and EVERY shouldn't work on arrays.
Proposal (SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS:MODIFIED):
Common Lisp already provides a facility called "displaced arrays"
which can be used to overlay one array on top of a portion of another,
even if the two are of different ranks, so that the two share storage.
Emphasize this as a way of explaining the behavior of sequence
functions on certain arrays.
Modify the definition of COERCE to allow the coercion of an array to
a vector and vice versa. In keeping with p51 of CLtL, it should be an
error if the result type has a different number of elements than the
object being coerced.
Extend the definitions of sequence functions that either return their
argument sequences, return sequences which are the same shape as their
argument, or return non-sequences so that they also allow arrays iff
their action is conceptually independent of the shape of the array.
The affected functions are COUNT, SOME, EVERY, NOTANY, NOTEVERY,
FILL, REPLACE, SUBSTITUTE, NSUBSTITUTE, and MAP.
Expressly forbid arrays as arguments to other sequence functions.
These other functions are LENGTH, ELT, FIND, POSITION, REDUCE, SEARCH,
MISMATCH, REVERSE, NREVERSE, SORT, MAP, SUBSEQ, COPY-SEQ, CONCATENATE,
MERGE, REMOVE, REMOVE-DUPLICATES, DELETE, DELETE-DUPLICATES.
Rationale:
This proposal would expand rather than interfere with existing practice.
Since displaced arrays are already part of Common Lisp, the cost of the
proposed changes would be very low.
If the change is not adopted, Common Lisp programmers who wish to use
arrays will have two choices. Either they must write nested DO loops
every time they want to perform an array operation equivalent to FILL,
REPLACE, etc., or else they can build displaced vectors by hand and
pass them to the sequence functions when necessary.
This proposal extends certain sequence functions in some interesting
ways without committing us to a theory of how arrays and sequences
relate that everyone may not be happy with right now.
Adoption Cost:
This would involve a lot of changes to functions, but all of them
presumably minor. The presence of displaced arrays in the language
already guarantees that the internal storage format needed to back
up these proposed changes is already in place.
Benefits:
Users of arrays do not have to use home-grown utilities to duplicate
functionality already primitively provided to users of arrays. The
sequence functions become useful in a variety of new situations.
Conversion Cost:
This change is `upward compatible.' User code should run unmodified.
Aesthetics:
This extends certain existing sequence functions to allow arrays
as arguments in a fairly non-controversial way, leaving aside the
larger issue of whether and how to generalize the other sequence
functions.
Current Practice:
Probably no one implements this now.
Discussion:
A more general version of this was introduced by Touretzky but
it was rejected by X3J13.
The members of the Cleanup committee expressed interest in the ideas
behind this proposal but weren't sure they could accept it in the
proposed form. A rewrite to separate some of the issues more clearly
was solicited. Rees suggested this subset of Tourtezky's proposal
might be interesting.
Note that the function REDUCE is in a gray area. Many of its uses
are not position-dependent, but some are. The same argument might
be made about FIND. If people felt strongly, these too could be
extended either by fudging the conservative rule or by explicit
special case(s), but they have been omitted to be conservative.
∂06-Oct-88 1532 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 15:31:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 15:30:03 PDT
Date: 6 Oct 88 15:29 PDT
From: masinter.pa@Xerox.COM
To: cl-cleanup@sail.stanford.edu
Subject: Issue: SETF-SUB-METHODS (Version 5)
Message-ID: <881006-153004-1550@Xerox>
This issue was last discussed on 10 June. I apparently passed over it
my last tour through the issues.
I rewrote the problem description and proposal in third person.
I added a "Performance Impact" section and made something up for it.
I moved some of the text from "Problem" and "Proposal" to "Discussion"
in an attempt to streamline it.
!
Issue: SETF-SUB-METHODS
References: CLtL pp. 95-96, 99, 105-106, 166
Issue: PUSH-EVALUATION-ORDER
Category: CLARIFICATION
Edit history: Version 1: JonL White & Ken D. Olum 12-Feb-88
(based on problem originally called SETF-METHOD-FOR-SYMBOLS)
Version 2: JonL White 23-May-88 (fix references and spellings).
Version 3: JonL White 25-May-88
Version 4: JonL White & Ken D. Olum 26-May-88 (final insights!)
Version 5: Masinter (respond to comments)
Problem description:
Implementations differ in the left-to-right order
of evaluation in the following form:
(setq r '(a 1 b 2 c 3))
(setq s r)
(setf (getf r 'b) (progn (setq r nil) 6))
In some implementations, the side-effect of the setq appears to happen before
the evaluation of the place form (getf r 'b) which is necessary to fetch the
list being updated. A typical result is 'r' = (B 6), 's' = (A 1 B 2 C 3)
after the operation.
There is a similar problem with SETF's over LDB, MASK-FIELD, and CHAR-BIT.
CLtL p99 is explicit about left-to-right order of evaluation.
However, the specification is less clear about computations involved
in "evaluation" of the subforms, and other computations that are implicit
in the notion of "doing an access" or "doing a store".
Proposal: SETF-SUB-METHODS:DELAYED-ACCESS-STORES
This proposal specifies more explicilty the behavior of SETF in the case
of access forms whose sub-forms are permitted to be generalized variable
references [and which thus need to call GET-SETF-METHOD during setf macro
expansion].
Remember, first, that GET-SETF-METHOD returns the following:
-- Some temporary variables
-- A list of value-producing forms
-- A list of store-variables (normally one).
-- A storing form.
-- An accessing form.
The code produced as the macro expansion of a SETF form that
itself admits a generalized variable as an argument must essentially
do the following major steps:
** It evaluates the value-producing sub-forms, in left-to-right order, and
binds the temporary variables to them. This will be called "binding the
temporaries."
** It "reads the value" from the generalized variable using the supplied
accessing form, to get the "old value"; this will be called "doing the
access." [Note that this is done after all the evaluations of the
preceeding step, including any side-effects they may have.]
** It binds the store-variable to a new value, and then installs this
new value into the generalized variable using the supplied "storing
form". This will be called "doing the store."
"Reading the value" of a generalized variable reference is not part of
the series of evaluations that must be done in left-to-right order.
The place-specifier forms listed at the top of CLtL p96 permit admit (other)
place-specifiers as arguments; during the SETF expansion of these forms, it
is necessary to call GET-SETF-METHOD in order to figure out how the inner,
nested generalized variable must be treated. This proposal requires GETF be
listed among these forms, since it must have a sub-recursive <place> specifier
[however, there is no Common Lisp function serving as a pseudo-update function
for it, the way DPB serves for LDB].
For each place-specifier form with a sub-recursive place specifier,
the information from GET-SETF-METHOD is used as follows.
CHAR-BIT:
In a form such as:
(SETF (CHAR-BIT <place-form> <bit-name>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to a character object itself.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <bit-name> (and bind into a temporary)
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form>, with the given bit-name of the
character fetched in step 4 changed to reflect the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different "bit" of the character --
then the change of the bit denoted by <bit-name> will be to that altered
character, because the "access" step is done after the <value-form>
evaluation. See example 1 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
LDB:
In a form such as:
(SETF (LDB <byte-spec> <place-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not to any object of type integer.
Thus this SETF should generate code to do the following:
1. Evaluate <byte-spec> (and bind into a temporary)
2. Bind the temporaries for <place-form>
3. Evaluate <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with the given bit-field of the integer
fetched in step 4 replaced with the value from step 3.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different bit-field of the integer --
then the change of the bit-field denoted by <byte-spec> will be to that
altered integer, because the "access" step is done after the <value-form>
evaluation. See example 2 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
MASK-FIELD:
This case is the same as LDB in all essential aspects.
GETF:
In a form such as:
(SETF (GETF <place-form> <ind-form>) <value-form>)
the place referred to by the <place-form> must always be both accessed
and updated; note that the update is to the generalized variable
specified by <place-form> -- not necessarily to the particular list
which is the property list in question.
Thus this SETF should generate code to do the following:
1. Bind the temporaries for <place-form>
2. Evaluate <ind-form> (and bind into a temporary)
3. Evaluate the <value-form> (and bind into the store variable)
4. Do the access to <place-form>
5. Do the store into <place-form> with a possibly-new property list
obtained by combining the values from steps 2, 3, and 4.
If the evaluation of <value-form> in step 3 alters what is found in the
given "place" -- such as setting a different named property in the list,
then the change of the property denoted by <ind-form> will be to that
altered list, because the "access" step is done after the <value-form>
evaluation. See example 7 in the test cases section. Nevertheless, the
evaluations required for binding the temporaries are done in steps 1 and
2, and thus the expected left-to-right evaluation order is seen.
Note that this phrase "possibly-new property list" treats the
implementation of property lists as a "black box" -- it can mean that
the former property list is somehow destructively re-used, or it can
mean partial or full copying of it. This is like the question of REMOVE
or DELETE -- do you copy or do you destructively alter. Since the answer
could go either way, the treatment of the resultant value for the
"possibly-new property list" must proceed as if it were a different copy
needing to be stored back into the generalized variable.
The "read-modify-write" macros such as INCF, DECF, PUSH, POP,
and REMF, as well as PSETF, SHIFTF, and ROTATEF should be
specified to have the same evalauation order for the subforms of
the "place" arguments; this would generally follow from their definition
in terms of SETF.
Test Cases:
1. (setq char (make-char #\A 1)) ==> #\Control-A
(rotatef (char-bit char :control)
(char-bit char :meta))
char ==> #\Meta-A
;; It's as if you start with #\Control-A, and then first turn the
;; :control bit off, because the :meta bit was originally off; and
;; then to the resulting #\A, you add the :meta bit since the
;; :control bit was originally on.
Note, however, that if an implementation doesn't support both of these
character 'bits', then this test case would have to be re-written to
reference two independent bits actually supported. If an implementation
supports fewer than two independent character bits, then this test case
is entirely moot.
2. (setq integer #x69) ==> #x69
(rotatef (ldb (byte 4 4) integer)
(ldb (byte 4 0) integer))
integer ==> #x96
;; This very-realistic example is simply trying to swap two
;; independent bit fields in an integer. Note that the generalized
;; variable of interest here is just the (possibly local) program
;; variable 'integer'.
3a.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (prog1 l1
(setq l1 nil)))))
l1 ==> nil
l2 ==> (#x99)
;; Note that the (setq l1 nil) didn't affect the actions of the setf
;; at all, since l1 was evaluated and its value was saved away in a
;; temporary variable as part of the step "2. Bind the temporaries
;; for <place-form>", and this was done before the evaluation of the
;; <value-form> which contains the (setq l1 nil). Note also that the
;; step "4. Do the access to <place-form>" means fetching the CAR of
;; the saved (temporary) value of 'l1'; it does not mean doing a LDB
;; on anything like that.
3b.(setq l1 (setq l2 (list #x69))) ==> (#x69)
(setf (ldb (byte 4 4) (car l1))
(ldb (byte 4 0) (car (rplaca l1 #x17))))
l1 ==> (#x77)
l2 ==> (#x77)
;; Note that the (rplaca l1 #x17) altered the contents of what l1
;; was pointing to. Thus even though l1 was evaluated and its
;; value was saved away in a temporary variable as part of the step
;; "2. Bind the temporaries for <place-form>", and even though this
;; was done before the evaluation of the <value-form> which contains
;; the rplaca, still the side-effect changes things because it alters
;; what will be fetched during the "do the access" step.
4. (setq integer #x69)
(setf (mask-field (byte 4 4) integer) (incf integer)) => #x6A
integer ==> #x6A
5. (setq integer #x6A)
(setf (mask-field (byte 4 4) integer) (ash (incf integer) 4)) => #x6B0
integer => #xBB
6. (setq s (setq r (list 'a 1 'b 2 'c 3))) ==> (a 1 b 2 c 3)
(setf (getf r 'b)
(progn (setq r nil) 6)) ==> 6
r ==> (b 6)
s ==> (a 1 b 2 c 3)
;; Note that the generalized variable of concern here is the (degenerate?)
;; one of simply the program variable 'r'; it is not a property-list
;; slot denoted by (getf r 'b). At the time the step "4. Do the access
;; to <place-form>" is performed, the evaluation of the <value-form>
;; has already altered the generalized variable 'r', and thus a nil is
;; returned for this access; that is why a fresh property-list (B 6) is
;; created an stored back into 'r'.
7. (setq s (setq r (list (list 'a 1 'b 2 'c 3)))) ==> ((a 1 b 2 c 3))
(setf (getf (car r) 'b)
(progn (setq r nil) 6)) ==> 6
r ==> nil
s ==> ((A 1 B 6 C 3))
;; Note that the (setq r nil) does not affect the actions of the setf
;; because the value of R had already been saved in a temporary variable
;; as part of the step "1. Bind the temporaries for <place-form>". Only
;; the CAR of this value will be accessed, and subsequently modified
;; after the value computation.
Rationale:
As a principle,
(setf (foo-a x) (progn (setf (foo-b x) ...)
new-a-value))
should always set both of the "slots" of 'x', even if these slots are
implemented as bit-fields, getf-properties, and so on. Only by separating
out evaluation from "generalized variable access", and by specifying that
the access is done after all the evaluations, can this correctly be done.
Current Practice:
Lucid Common Lisp already operates pretty much according to this proposal.
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. Symbolics Genera 7.1
is probably closer to this proposal.
Performance impact:
Small. This proposal might slow down macro-expansion slightly,
might cause some current optimizations not to work as well. However,
the net effect is likely negligible.
Cost to Implementors:
In some implementations, this would require a careful revisiting of
the handling of SETF and generalized variable modifiers.
Cost to Users:
Small; although this will impose an incompatible change on
implementations that don't behave as proposed, and might have
an effect on (non-portable) code, we believe the effects
are not widespread.
Cost of non-adoption:
SETF left-to-right order of evaluation will not be well specified;
implementations will differ for no good reason.
Benefits:
Uniform semantics and portability in the face of recursive "place specifiers"
for SETF. Setf of (LDB ... <place>) and of (GETF <place> ...) will behave
uniformly no matter the nature of the <place>.
Anyone who has copied examples from p105 and p106 will continue to
be able to use them.
Esthetics:
See "Cost of non-adoption"
Discussion:
This is a difficult proposal to specify.
In the detailed descriptions for each access form, the phrase
"the place referred to by the <place-form> must always be both
accessed and updated; note that the update is to the generalized
variable specified by <place-form>"
is not intended to prevent optimizations that could occur when the
code "knows" that the new value will be EQ to the old one. The only
requirements is that the results be semantically equivalent.
There is an interesting parallel between this case for GETF and the
very common mistake made by Lisp programmers with respect to the
function DELETE. How often the complaint is filed that DELETE didn't
do anything when it should have; but in fact the filer simply forgot
that delete, although permitted to destructively modify the original
list, may also return some tail of the list originally give it,
whether or not an alteration occurs.
(setq l '(a a b c d)) ==> (a a b c d)
(delete 'a l) ==> (b c d)
l ==> (a a b c d)
The unwary user thinks that because 'l' is still EQ to the original value
that "DELETE didn't do anything". The temptation to ignore the resultant
value of DELETE parallels the temptation to forget about a need to perform
a final update to <place-form> in the setf-of-getf case.
In the (degenerate?) case when a generalized variable
is in fact simply a program variable, then there are no sub-forms to be
considered "value-producing" forms; in fact, "doing the access" for such
a generalized variable (i.e. a program variable) is functionally the
same as evaluating it. This explains why the behaviour in the "Problem
Description" is at first perplexing -- the "do the access" step has the same
semantics as an evaluation step, even though it is done after all the
prescribed evaluations.
The issue PUSH-EVALUATION-ORDER is a clarification about just the point
of the evaluation order for the various subforms to a PUSH; thus there
is a similarity to this issue, but the present issue has a much deeper
problem because of the need to call GET-SETF-METHOD during setf macro
expansion.
∂06-Oct-88 1620 CL-Cleanup-mailer Issue: STREAM-INFO (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 16:19:22 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 16:16:56 PDT
Date: 6 Oct 88 16:16 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: STREAM-INFO (Version 5)
In-reply-to: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Tue, 27 Sep 88
10:23:46 EDT
To: Scott.Fahlman@B.GP.CS.CMU.EDU
cc: dick@wheaties.ai.mit.edu (Richard C. Waters),
CL-Cleanup@sail.stanford.edu
Message-ID: <881006-161656-1634@Xerox>
I have a stream that prints characters to a printer-independent file format
(think Postscript). I run in a system that admits 16-bit characters. The
character widths are cached, and loaded on demand. Character widths are
expressed in rationals. In advance of printing, I don't know what the
widths will be. Different type faces will have different units of
quantization.
As with postscript, the widths are expressed in absolutes independent of
the resolution of the printer -- the printer will perform "best effort" to
print things the same sizes as specified.
Suppose that I am using a style in which most characters are size R (where
R is an integer), but there are a few special symbols that are of size
R*732/539 . I'd prefer to normally use a scale where R is a small integer
rather than have to reduce everything to a scale where, in order to
accomodate the possibility of an unusual character, the scale has to bloat
to be unusually large.
Allowing sizes to be rational instead of integer is a performance
improvement; in a world where there are fairly arbitrary outline-defined
characters of arbitrary sizes, it might be necessary to resort to bignums
to accomodate the least common denominator of all of their sizes.
Rational numbers might drive some users insane, but I think for the most
part you want to allow the implementation to pick the appropriate scale.
My only thought is that, having thought that far, there is no reason to not
extend the range of character widths to allow for floating point, i.e., the
results is a (non-complex) number.
∂06-Oct-88 1623 CL-Cleanup-mailer Re: Issue: STRUCTURE-INFO (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 16:23:14 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 16:19:13 PDT
Date: 6 Oct 88 16:19 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STRUCTURE-INFO (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 24 Jun 88 13:59 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: CL-Cleanup@SAIL.STANFORD.EDU, DICK@WHEATIES.AI.MIT.EDU
Message-ID: <881006-161913-1642@Xerox>
Is this proposal still necessary?
Date: Tue, 20 Sep 88 19:46 PDT
From: Gregor.pa
Subject: Re: [Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>: Issue:
STRUCTURE-INFO (Version 1)]
To: masinter.pa
Fcc: BD:>Gregor>mail>outgoing-mail-4.text.newest
In-Reply-To: The message of 20 Sep 88 17:42 PDT from masinter.pa
Message-ID: <19880921024606.6.GREGOR@PORTNOY.parc.xerox.com>
Line-fold: no
I don't have time to write this up. But here is some code:
(defun structurep (x)
(typep (class-of x) 'structure-class))
(defun structure-contents (x)
(mapcar #'(lambda (slot-description)
(let ((name (slot-description-name slot-description)))
(list name (slot-value x name))))
(class-slots (class-of x))))
-------
∂06-Oct-88 1642 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 3
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 6 Oct 88 16:41:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 06 OCT 88 16:36:56 PDT
Date: 6 Oct 88 16:36 PDT
From: masinter.pa@Xerox.COM
Subject: SUBTYPEP-TOO-VAGUE, version 3
To: cl-cleanup@sail.stanford.edu
line-fold: NO
Message-ID: <881006-163656-1686@Xerox>
Issue: SUBTYPEP-TOO-VAGUE
References: CLtL p. 72-73
Category: CLARIFICATION
Edit History: Version 1, 11 Jul 1988 (Sandra Loosemore)
Version 2, 19 Jul 1988 (Sandra Loosemore)
Version 3, 6-Oct-88 (Masinter)
Problem Description:
The description of SUBTYPEP allows it to return a second value of NIL
when the relationship between the two types cannot be determined. In
some cases this is a reasonable thing to do because it is impossible
to tell (if the SATISFIES type specifier is involved), and in other
cases the relationships between types are not well-defined (for
example, the VALUES type specifier or the list form of the FUNCTION
type specifier).
Some implementations, however, have apparently interpreted this to
mean that it is permissible for SUBTYPEP to "give up" and return a
second value of NIL in some cases where it actually would be possible
to determine the relationship. This makes it difficult to depend on
subtype relationships in portable code.
Proposal: SUBTYPEP-TOO-VAGUE:CLARIFY
A type specifier "involves" a word like SATISFIES, MEMBER, NOT, etc.
if it either contains it directly or as the result of expansion of a DEFTYPE
defined type specifier.
* Clarify that SUBTYPEP will return a second value of NIL
only when either of the type specifiers involves the SATISFIES, NOT,
AND, OR, MEMBER.
* SUBTYPEP should signal an error when handed (for either argument)
a type specifier that involves VALUES or the list form of the FUNCTION
type.
* SUBTYPEP must always return values T T in the case where the two
type specifiers (or their expansions) are EQUAL.
* Clarify that the relationships between types reflected by SUBTYPEP
are those specific to the particular implementation. For example, if
an implementation supports only a single type of floating-point numbers,
in that implementation (SUBTYPEP 'FLOAT 'LONG-FLOAT) would return T T
(since the two types would be identical).
Rationale:
It is generally conceded that it is impossible to determine the
relationships between types defined with the SATISFIES specifier.
MEMBER, AND, OR, and NOT are messy to deal with.
Current Practice:
The implementation of SUBTYPEP in (the original) HPCL does not try to
expand type specifiers defined with DEFTYPE and does not recognize
EQUAL type specifiers as being equivalent. Most other implementations
appear to be substantially in conformance with the proposal.
Cost to implementors:
Some implementations will have to rewrite and/or extend parts of SUBTYPEP.
Cost to users:
Its hard to imagine a portable program that depends heavily
on SUBTYPEP. This proposal does not require any implementation
to "handle" fewer cases of SUBTYPEP.
Benefits:
An area of confusion in the language is cleared up. Usages of SUBTYPEP
will be more portable.
Discussion:
The handling of FLOAT and SINGLE-FLOAT appeared to be the
consensus from a discussion on the common-lisp mailing list some
time ago.
It would not be too onerous to require implementations to handle
the cases where one but not the other type specifier involves
OR, AND, NOT or MEMBER, but the specification becomes
cumbersome.
A related issue is clarifying what kinds of type specifiers must be
recognized by functions such as MAKE-SEQUENCE and COERCE. For example,
HPCL complains that (SIMPLE-ARRAY (UNSIGNED-BYTE *) (*)) is not a valid
sequence type when passed to MAKE-SEQUENCE, although SUBTYPEP does
recognize it to be a subtype of SEQUENCE. Should this proposal be
extended to deal with these issues, or is another proposal in order?
Do the rules for comparing the various type specifiers (such as ARRAY)
need to be spelled out in detail, or are they obvious?
∂06-Oct-88 1649 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 5)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 16:49:12 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 6 Oct 88 19:46:58 EDT
To: masinter.pa@Xerox.COM
cc: dick@wheaties.ai.mit.edu (Richard C. Waters),
CL-Cleanup@sail.stanford.edu
Subject: Re: Issue: STREAM-INFO (Version 5)
In-reply-to: Your message of 06 Oct 88 16:16:00 -0700.
<881006-161656-1634@Xerox>
Date: Thu, 06 Oct 88 19:46:23 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Well, if there really are useful real-world cases where it makes sense to
have most characters be of width R except a couple that are R*732/539, then
I guess it is necessary to go with rational widths, despite the cost in
performance and added confusion. (I'm assuming that you're not
exaggerating -- if the case is really R*3/2 then the decision is much less
clear.)
I don't violently object to the added complexity. I just didn't want to
add it for no good reason.
-- Scott
∂06-Oct-88 1755 CL-Cleanup-mailer Re: several hundred ugly things
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 17:55:21 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 6 Oct 88 20:52:32 EDT
To: masinter.pa@Xerox.COM
cc: CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: several hundred ugly things
In-reply-to: Your message of 06 Oct 88 10:09:00 -0700.
<881006-101028-2851@Xerox>
Date: Thu, 06 Oct 88 20:51:36 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
There's some desire in some parts of ISO to make Common Lisp "smaller". I'd
just as soon see it done carefully -- rather than with an axe. If you can
think of several hundred things that could be done to Common Lisp that
would make it smaller and not as ugly, perhaps you could help name a few?
The point of my comment about hundreds of ugly things was that if we throw
a few existing features out of the standard on aesthetic grounds, we would
open the door to demands that we throw hundreds of other things out. I
thought our charter was to introduce incompatible changes only if
necessary, and not on strictly aesthetic grounds.
But to address the question you raise...
It seems to me that we could coherently divide the language into two
levels: a kernel of necessary low-level functions and special forms, and a
set of functions that can be straightforwardly implemented in terms of
these kernel mechanisms. It would be fairly easy to assemble a body of
public-domain code that implements the outer layer, though this
implementation might not be optimally efficient for all machines. Nobody
would want to use a language that had just the kernel stuff, but making the
division explicit might be of some use to implementors and to people
doing formal analysis of programs.
I have never seen a principled proposal for a Common Lisp subset that
includes some amount of non-kernel functionality. If a person uses feature
X and not feature Y, then X goes in the proposed subset and Y is
"obviously" superfluous. Unfortunately, people write different kinds of
programs and have different programming styles; if you take the union of
things that people use in practice, you end up with the current language
and then some.
Instead of inventing some arbitrary standard subset of Common Lisp -- wrong
for every application but the one the subset committee had in mind -- I
have always favored the idea of building a delivery mode into commercial
Lisp systems. You develop your program using whatever parts of the full
language you need, then compile in a way that trims away anything that
wasn't used. This creates a subset of Common Lisp that exactly fits the
needs of the application in question. A simple version of this is trivial
to implement in any system that has a copying GC; with more effort, one
could eliminate parts of large functions, such as the code to implment
CIRCLE-PRINTING FORMAT's hairy numeric options, if an application doesn't
need them. I've never understood why the commercial vendors haven't put
more effort intot his sort of thing -- seems like there would be a market
for this, especially in systems that cross-compile to PC's and Macs.
So I don't have a list of things that I think we should flush in order to
make the language smaller. It seems to me that if we are not going to
reduce the size of the core image significantly (say, more than 20%), then
it's not worth throwing things out at all. Why make conversion hassles for
people when there is no significant reduction in core size or language
complexity. The only things I'd propose to throw out are those things we
can't quite get right or can't explain coherently -- the whole pathname
system comes to mind, along with *EVALHOOK* and *APPLYHOOK*. And maybe the
compiler. :-)
-- Scott
∂06-Oct-88 1851 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 18:51:33 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472291; Thu 6-Oct-88 21:50:04 EDT
Date: Thu, 6 Oct 88 21:49 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881006214951.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
I just added a few remarks in the Discussion.
-----
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
Status: For Internal Discussion
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards. For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
CL code needs to at least be able to detect and possibly to manipulate
such wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTION):
Introduce the following function:
WILD-PATHNAME-P pathname &optional field-key [Function]
Tests a pathname for the presence of wildcard components.
If the first argument is not a pathname an error is signalled.
If no field-key is provided, or the field-key is NIL, this function
returns true if the argument pathname has any wildcard components.
Otherwise, it returns false.
If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
if the argument pathname is wild in the indicated component. Otherwise,
it returns false.
Test Case:
#1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
#2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
#3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
#4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
#4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
Rationale:
If the programmer can at least detect wild pathnames reliably,
he can know to do something useful (give up, merge out the bothersome
components, call DIRECTORY for a list of matching pathnames, etc.)
Current Practice:
Presumably no implemenation supports the proposal exactly as stated.
Symbolics Genera provides the ability to do
(SEND pathname :WILD-P)
which returns a value such as NIL, :NAME, :TYPE, etc. In the case
that more than one field is wild, however, some information is lost.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcarded code to write it (often more heuristically).
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
situations which CL pathnames cannot represent.
Benefits:
Portable user interfaces that prompt users for pathnames could more
reliably detect wildcard pathnames and more easily guard against
embarrassing behavior in such situations.
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
Pitman supports PATHNAME-WILD:NEW-FUNCTION.
It would have been possible for this function to have accepted
a string as an argument (coercing it to a pathnames), but that
would have entailed adding an optional host argument. We opted
not to do this.
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
∂06-Oct-88 1852 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 18:52:19 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 472292; 6 Oct 88 21:50:40 EDT
Date: Thu, 6 Oct 88 21:50 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
Supersedes: <881006214951.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <881006215027.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I just added a few remarks in the Discussion.
-----
Issue: PATHNAME-WILD
References: Pathnames (pp410-413)
Category: ADDITION
Edit history: 21-Jul-88, Version 1 by Pitman
06-Oct-88, Version 2 by Pitman
Status: For Internal Discussion
Problem Description:
Some file systems provide more complex conventions for wildcards than
simple component-wise wildcards. For example,
"F*O" might mean:
- a normal three character name
- a three-character name, with the middle char wild
- at least a two-character name, with the middle 0 or more chars wild
- a wild match spanning multiple directories
">foo>*>bar" might imply:
- the middle directory is named "*"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any one-letter name
">foo>**>bar" might mean
- the middle directory is named "**"
- the middle directory is :WILD
- there may be zero or more :WILD middle directories
- the middle directory name matches any two-letter name
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
CL code needs to at least be able to detect and possibly to manipulate
such wildcard pathnames.
Proposal (PATHNAME-WILD:NEW-FUNCTION):
Introduce the following function:
WILD-PATHNAME-P pathname &optional field-key [Function]
Tests a pathname for the presence of wildcard components.
If the first argument is not a pathname an error is signalled.
If no field-key is provided, or the field-key is NIL, this function
returns true if the argument pathname has any wildcard components.
Otherwise, it returns false.
If a non-null field-key is provided, it must be one of :HOST, :DEVICE,
:DIRECTORY, :NAME, :TYPE, or :VERSION. In this case, it returns true
if the argument pathname is wild in the indicated component. Otherwise,
it returns false.
Test Case:
#1: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD)) => T
#2: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :NAME) => T
#3: (WILD-PATHNAME-P (MAKE-PATHNAME :NAME :WILD) :TYPE) => NIL
#4: (WILD-PATHNAME-P (PATHNAME "S:>foo>**>")) => T ;Lispm
#4: (WILD-PATHNAME-P (PATHNAME :NAME "F*O")) => T ;Most places
Rationale:
If the programmer can at least detect wild pathnames reliably,
he can know to do something useful (give up, merge out the bothersome
components, call DIRECTORY for a list of matching pathnames, etc.)
Current Practice:
Presumably no implemenation supports the proposal exactly as stated.
Symbolics Genera provides the ability to do
(SEND pathname :WILD-P)
which returns a value such as NIL, :NAME, :TYPE, etc. In the case
that more than one field is wild, however, some information is lost.
Cost to Implementors:
Many implementations probably have a substrate which is capable of this
or something similar already. In such cases, it's a relatively small
matter to add the proposed interface.
Even in cases where an implementation doesn't have ready code, it's clearly
better for the implementor to write that code once and for all than to ask
each user of wildcarded code to write it (often more heuristically).
Cost to Users:
None. This change is upward compatible.
Cost of Non-Adoption:
Wild pathnames would continue to be mistaken for ordinary pathnames in
situations which CL pathnames cannot represent.
Benefits:
Portable user interfaces that prompt users for pathnames could more
reliably detect wildcard pathnames and more easily guard against
embarrassing behavior in such situations.
Aesthetics:
This change would make some portable code less kludgey.
Discussion:
Pitman supports PATHNAME-WILD:NEW-FUNCTION.
It would have been possible for this function to have accepted
a string as an argument (coercing it to a pathnames), but that
would have entailed adding an optional host argument. We opted
not to do this.
There was some question about the name. The name PATHNAME-WILD-P
suggests a ``slot'' of a pathname (like PATHNAME-HOST),
while WILD-PATHNAME-P suggests a type (like INPUT-STREAM-P).
The committee was split on what to call it. Since it is more
like a type than a slot, the name WILD-PATHNAME-P was chosen.
∂06-Oct-88 1909 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
Received: from REAGAN.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:09:14 PDT
Received: from JACKIE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 141293; Thu 6-Oct-88 22:07:49 EDT
Date: Thu, 6 Oct 88 22:07 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
Reply-To: Mly-lisp@MC.LCS.MIT.EDU
Subject: Issue: PATHNAME-WILD (Version 2)
To: KMP@STONY-BROOK.SCRC.SYMBOLICS.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881006214951.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881007020748.5.MLY@JACKIE.AI.MIT.EDU>
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
This is not even `portable' code for creating a wildcarded pathname.
How do you distinguish between pathname named "f*o" and a wildcarded
pathname which starts with an #\f and ends with an #\o?? (BTW, the
Symbolics pathname system ducks the entire issue.)
The pathname specification is so crippled that adding dinky frobs like
PATHNAME-WILD-P isn't going to make any difference to `portability' --
about all it will add is another page to the CL manual.
∂06-Oct-88 1958 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:58:04 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 472317; 6 Oct 88 22:35:25 EDT
Date: Thu, 6 Oct 88 22:35 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: Mly-lisp@MC.LCS.MIT.EDU
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881007020748.5.MLY@JACKIE.AI.MIT.EDU>
Message-ID: <881006223513.5.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Thu, 6 Oct 88 22:07 EDT
From: Richard Mlynarik <MLY@AI.AI.MIT.EDU>
The CL pathname model does not provide a way to represent such wildcards,
which means, for example, that (MAKE-PATHNAME :NAME "F*O") cannot be
recognized by portable code as containing a wildcard.
This is not even `portable' code for creating a wildcarded pathname.
How do you distinguish between pathname named "f*o" and a wildcarded
pathname which starts with an #\f and ends with an #\o?? (BTW, the
Symbolics pathname system ducks the entire issue.)
The pathname specification is so crippled that adding dinky frobs like
PATHNAME-WILD-P isn't going to make any difference to `portability' --
about all it will add is another page to the CL manual.
The purpose of this isn't to say what's wild, it's to give portable code
a way to guard against wildcards.
Sample portable program that it is not possible to write correctly now
but would be after this proposal:
(DEFUN SHOW-FILE (FILE) ;Allows wildcards
(DOLIST (FILE (IF (PATHNAME-WILD-P FILE)
(DIRECTORY FILE)
(LIST FILE)))
(WITH-OPEN-FILE (STREAM FILE)
(DO ((LINE (READ-LINE STREAM NIL NIL) (READ-LINE STREAM NIL NIL)))
((NOT LINE))
(FORMAT T "~&~A~%" LINE)))))
∂06-Oct-88 1958 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 19:58:04 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472326; Thu 6-Oct-88 22:49:32 EDT
Date: Thu, 6 Oct 88 22:49 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881005-005724-4531@Xerox>
Message-ID: <19881007024901.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I mostly agree with version 5, but found that it didn't address all of
my concerns presented in June and in private discussions with JonL. To
be constructive, I've made a new version of the proposal, instead of
just commenting. The changes are:
- fix typographical errors
- use the same terminology as CLtL as much as possible
- cover SUBTYPEP in the proposal, not just in the test case
- cover all cases of declaration vs. discrimination (i.e. add COMPLEX)
- add a complete list of affected type-specifiers
- change the name of UPGRADE-ARRAY-ELEMENT-TYPE
- change the presentation of the proposal to make it easier to understand
- numbered the proposal points, and added a summary of them, to
make the proposal easier to discuss
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination". Many people are confused by
this situation, which may be one of the more insidious flaws in the
current CL design. A consequence of this "flaw" is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have *none* of its
values ever satisfy the typep predicate with that type-specifier.
One type-specifier with this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". Change the meaning of the <element-type> in the
ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
Specify how SUBTYPEP behaves on these type-specifiers. Add a function
to provide access to the implementation-dependent set of array types
and another function to provide access to the implementation-dependent
set of complex number types.
1. Eliminate references to the distinction between types "for declaration"
and "for discrimination" in the discussion of array and complex
type-specifiers. This would include documentation patterned after CLtL:
a.) The discussion in section 4.5, pp. 45-7
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Instead, (ARRAY <type>) always means all arrays that can result by specifying
<type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
only if <x> is an array of the most specialized representation capable
of holding elements of type <type>. In other words, it is true if and
only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is the same
type-specifier as (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
Do the same for SIMPLE-ARRAY and VECTOR.
3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding components of type <type>,
or <x> is of any subtype of that representation.
4. Define that for all type-specifiers <type1> and <type2>, other than *,
(ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
depending on whether they use the same specialized representation or
distinct representations. This defines the behavior of SUBTYPEP.
5. Define that for all type-specifiers <type1> and <type2>, other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
same specialized representation, T T if they use distinct specialized
representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
otherwise.
6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
:ELEMENT-TYPE argument. Thus the set of specialized array
representations must be consistent between single-dimensional and
multi-dimensional, simple and non-simple, short and long arrays.
7. Add the function IMPLEMENTATION-ARRAY-ELEMENT-TYPE which returns the
same result as
(DEFUN IMPLEMENTATION-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
<type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
the same value from IMPLEMENTATION-ARRAY-ELEMENT-TYPE, and disjoint
otherwise.
8. Add the function IMPLEMENTATION-COMPLEX-COMPONENT-TYPE which returns
the component type of the most specialized complex number
representation that can hold components of the given type.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
The small differences between the specification for ARRAY and the
specification for COMPLEX are necessary because there is no
MAKE-COMPLEX function, thus in the case of COMPLEX we must refer to the
type of the components, and a number can be a member of more than one
type. Thus
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
is true in all implementations, but
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is only true in implementations that do not have a specialized array
representation that can hold single-floats but not other floats.
Current Practice:
Every vendor's implementation that the proposer has queried has a
finite set of specialized array representations, such that two
non-equivalent element types can be found that use the same specialized
array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other vendors fail it.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of typep and subtypep.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about make-array
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(make-array <n> :element-type '<type>) frequently is not of type
(array <type>) has been very confusing to almost everyone. That is, in
practice, the distinction between "for declaration" and "for
discrimination" has been a disaster.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
To get a sense of how the community is confused, see the arpanet mailing
list for Common Lisp, in a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications".
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP
should be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been
proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I
don't see how to eliminate "array element type upgrading" without
creating more problems [than] we solve. . . .
My conclusion [JonL's] is that it isn't array types that are wrong,
it is the understanding of the meaning of TYPEP that is wrong.
Many persons are in favor of the permission to upgrade; but they would
not like to see CL become a language like C where there are a
prescribed set of kinds of arrays that must be implemented (e.g, "int",
"long int", "single", "double" etc), and no others can exist. In short,
no one would want to gain portability at the expense of limiting the
language to the architectural features of the hardware on which it was
first implemented.
It may also be the case that portability will be improved since the
identity
(typep (make-array N :element-type '<type>) '(array <type>)) will be
observed.
∂06-Oct-88 2002 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:02:05 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00937g; Thu, 6 Oct 88 20:00:50 PDT
Received: by bhopal id AA07175g; Thu, 6 Oct 88 19:59:09 PDT
Date: Thu, 6 Oct 88 19:59:09 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810070259.AA07175@bhopal>
To: masinter.pa@Xerox.COM
Cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: masinter.pa@Xerox.COM's message of 5 Oct 88 20:47 PDT <881005-204718-2157@Xerox>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Correction: Lucid Common Lisp 3.0 implements the proposed suggestion.
I belive Chris simply tried it out on a very early "beta" release of
LCL3.0; but the product version indeed has this lacuna fixed.
-- JonL --
∂06-Oct-88 2057 CL-Cleanup-mailer Issue: DECLARE-TYPE-FREE (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 20:46:33 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472344; Thu 6-Oct-88 23:45:12 EDT
Date: Thu, 6 Oct 88 23:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-TYPE-FREE (Version 5)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <880930-213354-1766@Xerox>
Message-ID: <19881007034441.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
DECLARE-TYPE-FREE:ALLOW in version 5 is okay with me except for
the formatting errors (presumably introduced by the Xerox mailer
line-folding) and the omission of the word "not" before "be" in
"it would be bad style to have inner declarations be subtypes of the
outer ones." I haven't asked him, but I think this missing word is what
really provoked Kent's comments.
∂06-Oct-88 2115 CL-Cleanup-mailer Issue: DEFPACKAGE (version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:14:39 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472357; Fri 7-Oct-88 00:13:11 EDT
Date: Fri, 7 Oct 88 00:12 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 5)
To: CL-Cleanup@Sail.stanford.edu
In-Reply-To: <881001-012210-1872@Xerox>
Message-ID: <19881007041242.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I almost approve version 4, but there are a couple of problems with it
(enumerated below). In the interest of saving time, here is a version 5
with the problems fixed and no other changes. Naturally I approve it.
- fix trivial typos
- the complex forms of :IMPORT-FROM and :SHADOWING-IMPORT-FROM can
be removed if the prohibition against repeated options is lifted.
This seems like a worthwhile simplification.
- the change to :IMPORT-FROM and :SHADOWING-IMPORT-FROM to call
FIND-SYMBOL instead of INTERN inadvertently made them useless,
since there is no way to assure that non-exported, non-shadowed
symbols exist. Add a :INTERNAL option to take care of this.
- change current practice to note that this is an incompatible change
for Symbolics
- specify what happens if the package already exists
Issue: DEFPACKAGE
References: CLtL section 11.7.
Issue: IN-PACKAGE-FUNCTIONALITY
Category: ADDITION
Edit history: Version 1, 12-Mar-88, Moon
Version 2, 23-Mar-88, Moon, changes based on discussion
Version 3, 27-Sep-88, JonL
(remove :import, :shadowing-import; allow :export to work on
imported and inherited; update references to in-package, etc.)
Version 4, 1-Oct-88, Masinter
Version 5, 6-Oct-88, Moon
Problem description:
The package functions included in CLtL encourage a programming style
that tends to evoke the worst aspects of the package system. The
problem is that if the definition of a package is scattered through
a program, as a number of individual forms, it is very easy to read
a symbol before the package setup needed to read that symbol correctly
has been accomplished. Three examples: an inherited symbol that should
have been shadowed might be accessed; a single-colon prefix might be
used for a symbol that will later be exported, causing an error; a local
symbol might be accessed where a symbol that will later be imported or
inherited was intended. These problems can be difficult to understand
or even to recognize, are difficult to recover from without completely
restarting the Lisp, and frustrating to programmers.
Proposal (DEFPACKAGE:ADDITION):
Add a DEFPACKAGE macro to the language. In the description below,
'package-name' and 'symbol-name' can be a symbol or a string; if a symbol,
only its name matters, not what package it is in. If a string, capitalization
matters, normally uppercase is used.
The syntax of DEFPACKAGE is
(DEFPACKAGE package-name {option}*)
where each option is a list of a keyword and arguments. Nothing in a
DEFPACKAGE form is evaluated.
Standard options for DEFPACKAGE are listed below. Options may appear
more than once (useful mainly for :IMPORT-FROM and :SHADOWING-IMPORT-FROM).
It is an error to specify :SIZE more than once.
(:NICKNAMES {package-name}*)
Set the package's nicknames to the specified names.
(:USE {package-name}*)
Inherit from the specified packages.
(:SHADOW {symbol-name}*)
Create the specified symbols in the package being defined, and
place them on the shadowing symbols list.
(:SHADOWING-IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined, and place them on the
shadowing symbols list. In no case will
symbols be created in any package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:IMPORT-FROM package-name {symbol-name}*)
Find the specified symbols in the specified package and import
them into the package being defined. In no case will
symbols be created in a package other than the one being defined;
a continuable error is signalled if no symbol is accessible in the
package named package-name for one of the symbol-names.
(:EXPORT {symbol-name}*)
Find or create symbols with the specified names and export them.
Note an interaction with the :USE option, since intern'ing may inherit
symbols rather than creating new ones; note also an interaction
with the :IMPORT-FROM and :SHADOWING-IMPORT-FROM options, since
intern'ing will merely access an already imported symbol.
(:INTERNAL {symbol-name}*)
Find or create symbols with the specified names. This is useful
if a :IMPORT-FROM or :SHADOWING-IMPORT-FROM option in a later
DEFPACKAGE for another package expects to find these symbols,
but the symbols are not to be exported.
(:SIZE integer)
Declare the approximate number of symbols expected in the package.
This is an efficiency hint only, so that the package's table will
not have to be frequently re-expanded when new symbols are added
to it (e.g., by reading in a large file "in" that package.)
Additional options might be allowed by an implementation;
implementations should signal an error if an option not recognized by
that implementation is present.
The collection of symbol-name arguments given to the options :SHADOW,
:INTERNAL, :IMPORT-FROM, and :SHADOWING-IMPORT-FROM must all be
disjoint; an error is signalled otherwise. In a chronological sense,
the :EXPORT may be thought of as occurring last so that it can make
reference to inherited or imported symbols already created by the other
options.
DEFPACKAGE creates the package as specified, and returns it as its
value. It has no other side effects; i.e., it does not do an
IN-PACKAGE. If a package with the specified name already exists, the
existing package is modified, by adding to its attributes but not
removing any (for example EXPORT may be called, but UNEXPORT is never
called).
Examples:
;;; Play it super-safe, and use only strings as names; do not even
;;; assume that the package it is read in to "uses" LISP; do *not* create
;;; any symbols whatsoever in the package that it is read in to.
(LISP:DEFPACKAGE "MY-PACKAGE"
(:NICKNAMES "MYPKG" "MY-PKG")
(:USE "LISP")
(:SHADOW "CAR" "CDR")
(:SHADOWING-IMPORT-FROM "VENDOR-COMMON-LISP" "CONS")
(:IMPORT-FROM "VENDOR-COMMON-LISP" "GC")
(:EXPORT "EQ" "CONS" "FROBOLA")
)
;;; A similar call, using symbols rather than strings as names; expects
;;; to be read in to a package that "uses" LISP, and *may* create
;;; random internal symbols in that package (such as MY-PACKAGE etc).
(DEFPACKAGE MY-PACKAGE
(:NICKNAMES MYPKG :MY-PKG)
(:USE LISP)
(:SHADOW CAR :CDR #:CONS)
)
Rationale:
The availability of DEFPACKAGE encourages putting the
entire definition of a package in a single place. It also encourages
putting all the package definitions of a program in a single file, which
can be loaded before loading or compiling anything that depends on those
packages. This file can be read in the USER package, avoiding any
package bootstrapping issues.
In addition, DEFPACKAGE allows a programming environment to process
the whole package setup as a unit, providing better error-checking and
more assistance with package problems, by dint of global knowledge of
the package setup.
Current practice:
Symbolics Common Lisp has always had a DEFPACKAGE, and uses it in
preference to individual calls to EXPORT, IMPORT, SHADOW, etc. The SCL
version of DEFPACKAGE has quite a few additional options, but none of them
appear to be necessary to propose for Common Lisp at this time. This
proposal is incompatible with Symbolics DEFPACKAGE in some ways that
will probably not cause major problems.
Cost to Implementors:
Small; DEFPACKAGE can be implemented simply as a bunch of
calls to existing functions.
Cost to Users:
Small, this is upward compatible.
Cost of non-adoption:
Packages continue to be difficult to use correctly.
Benefits:
Guide users away from using packages in ways that get them into trouble.
Esthetics:
Neutral.
Discussion:
The "Put in seven extremely random user interface commands" mnemonic
described in CLtL p.191 could be removed, and the special compiler
handling of these functions necessary to support that could be removed
(except possibly for REQUIRE and PROCLAIM -- see the compiler Issue
PROCLAIM-ETC-IN-COMPILE-FILE). As this would be an incompatible change,
it is not part of this proposal.
The issue IN-PACKAGE-FUNCTIONALITY recommends that IN-PACKAGE be
incompatibly changed to recognize only existing packages, not to create
them. IN-PACKAGE would then not accept any keyword arguments.
The function MAKE-PACKAGE might also be extended to take all the keywords
that DEFPACKAGE does. This could be the subject of a separate cleanup.
The macroexpansion of DEFPACKAGE can usefully canonicalize
into the strings-as-name form, so that even though the source file
showed random symbols in the DEFPACKAGE form, the compiled file might
have only strings in it.
Frequently additional implementation-dependent options take the
form of a keyword standing by itself as an abbreviation for a list
(keyword T); this syntax should be properly reported as an unrecognized
option in implementations that do not support it.
∂06-Oct-88 2118 CL-Cleanup-mailer Issue: DEFPACKAGE (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:18:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472358; Fri 7-Oct-88 00:17:13 EDT
Date: Fri, 7 Oct 88 00:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881006041254.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881007041654.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 6 Oct 88 04:12 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
I have some (mostly non-technical) wording gripes which I think should
be made for clarity...
Oops, I didn't see this message before I made a revised version.
I generally agree with Kent's comments here, but I also don't think
any of them are important enough to block adoption, so I'm not
going to take the time to make another revised version.
∂06-Oct-88 2124 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 6 Oct 88 21:24:29 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472359; Fri 7-Oct-88 00:23:04 EDT
Date: Fri, 7 Oct 88 00:22 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
To: cl-cleanup@sail.stanford.edu
cc: Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: <881005-204718-2157@Xerox>
Message-ID: <19881007042246.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
Circularities need only be detected for
objects that would normally be printed by the default structure
print-function.
I cannot accept any proposal with this kludgey restriction in it. If
circularities are going to be detected at all, they should be done
right. It's not difficult to call the user-defined print-function once
with a special stream argument that detects what the function prints
(i.e. what calls to WRITE and equivalent functions and FORMAT directives
it makes using that stream), and use that for circularity detection.
That's how the Symbolics Genera implementation works.
∂06-Oct-88 2220 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Oct 88 22:20:19 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01038g; Thu, 6 Oct 88 22:19:08 PDT
Received: by bhopal id AA07620g; Thu, 6 Oct 88 22:17:28 PDT
Date: Thu, 6 Oct 88 22:17:28 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810070517.AA07620@bhopal>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 23 Sep 88 01:19 PDT <880923-011851-3969@Xerox>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
Issue: MAKE-PACKAGE-USE-DEFAULT
References: MAKE-PACKAGE, CLtL p183
"USER" package, CLtL p181
Related issues: PACKAGE-CLUTTER
Category: CHANGE
Edit history: JonL White, 6-Oct-88 (version 1)
Problem description:
CLtL is underspecified as how to treat vendor-specific extensions to
the language; and every vendor has a fairly large set of such extensions.
A general understanding came over the community during 1986 that vendors
should "home" their extensions in a vendor-specific package, and not in
any of the packages named in CLtL section 11.6 "Built-in Packages". Just
how these symbols would be accessible to the user, however, was not stated.
All current means of providing "unqualified accessibility" to the
vendors' extensions will violate either some trivial part of CLtL, such
as the default :use list for MAKE-PACKAGE, or the prohibition of adding
non-standard symbols to the LISP package, or the apparent charge that
the USER package should use (only) the LISP package.
Proposal MAKE-PACKAGE-USE-DEFAULT:IMPLEMENTATION-DEPENDENT
Specify that the default value for the :use argument to MAKE-PACKAGE is
implementation-dependent; portable code would thus have to explicitly
designate the LISP package as the :use argument. Vendors are encouraged
to put their vendor-specific package on the default list, along with the
LISP package and any other packages so specified by the new standard.
Examples:
(package-use-list (make-package "SOME-USER"))
(package-use-list "USER")
Test Cases:
(assert
(subsetp `(,(find-package "LISP"))
(package-use-list (or (find-package "SOME-USER")
(make-package "SOME-USER")))))
Rationale:
Every vendor either already does the equivalent of this, or else has
a confusing assymetry about the USER package (i.e., their propietary
extensions are "available" in USER, but not in SOME-USER).
Current practice:
TI and Lucid's 3.0 versions "implement" this proposal in that they set
the default :use argument to be a list of the LISP package and the
vendor-specific package.
VAXLISP has renamed the LISP package to be the same as the vendor-specific
package, which contains the 775 symbols supposed to be in the LISP packge
along with all the vendors extensions; the package named COMMON-LISP
has only the 775. Thus this "implements" the proposal in the sense that
the inheritance of a package made with a default :use list contains
all the vendor-specific symbols -- not just the 775 "LISP" ones.
Symbolics release 7, and Lucid's 2.1 release use only '("LISP") for the
default MAKE-PACKAGE use list, but have the aforementioned assymetry
about the USER package.
Cost to Implementors:
None; this relaxes a constraint imposed by CLtL.
Cost to Users:
In theory, every user porting code from one vendor to another would
have to ensure that every package definition, via IN-PACKAGE or
MAKE-PACKAGE, had an explicit :use list. This is probably at most
a 5-minute text editor search. But in fact this imposition is moot,
since virtually every such user has *already* supplied explicit
:use lists; given the current practice, he has had no alternative.
Cost of non-adoption:
There will continue to be a lack of clear standardization in this area,
especially since vendors are more willing to violate this apparently
unuseful mandate from CLtL than they are to give up a minor bias towards
their customer base.
Performance impact:
None.
Benefits:
This new default behaviour for package creation will permit a vendor's
documented extensions to appear on equal footing with the basic facilities
in the LISP package. It appears as though the _majority_ of any vendors'
customers are developing and running their code totally within the
enviornment provided by that one vendor; hence it seems reasonable for
vendors to bias their default use list towards those customers making
frequent use of their specific extensions to Common Lisp.
Esthetics:
Some feel that fewer implementation-dependent loopholes in the language
is preferable, even when the practical import is virtually moot.
Discussion:
Lucid "exposes" the default :use list as the value of the special
variable *DEFAULT-MAKE-PACKAGE-USE-LIST*, so that at site-configuration
time, one could do
(setq *DEFAULT-MAKE-PACKAGE-USE-LIST* '("LISP"))
to return to the 1984 CLtL behaviour. [This is not being proposed
at this time.]
∂07-Oct-88 0017 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 00:17:11 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01093g; Fri, 7 Oct 88 00:16:01 PDT
Received: by bhopal id AA07902g; Fri, 7 Oct 88 00:14:21 PDT
Date: Fri, 7 Oct 88 00:14:21 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810070714.AA07902@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
This is revised at long last. Moon and I agree on the new syntax.
Note also that the hash-table return value sequence was changed to
accord with more peoples' expectations (i.e., <key> before <value>)
-- JonL --
!
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that each invocation (<next-fn>) will return
the successive items from the hash-table which is the value of
the expression <hash-table>. Iterating over such a form will thus
make the contents of the hash-table available one at a time. An
invocation (<next-fn>) returns three values as follows:
;; 1. a boolean to indicate no more entries (T says "there are more")
;; 2. the key item (of a <key, value> pair)
;; 3. the value item (of a <key, value> pair)
;; If there are no more entries in the hash-table, then only one
;; value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package> <type>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that each invocation (<next-fn>) will return
the successive items from the package which is the value of the
expression <package>. Iterating over such a form will thus make the
contents of the package available one at a time. The <type> argument
may assume any of the following values, indicating the sort of
symbols wanted:
DO-SYMBOLS ;any available symbol
DO-EXTERNAL-SYMBOLS ;just the :external symbols
DO-INTERNAL-SYMBOLS ;just the :internal symbols
DO-PRESENT-SYMBOLS ;both :internal and :external symbols
DO-ALL-SYMBOLS ;all symbols;
When <type> evaluates to DO-ALL-SYMBOLS, the <package> argument is
ignored. An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean to indicate no more entries (T says "there are more")
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol, (i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED).
;; If there are no more symbols available from the package, then only
;; one value is returned, namely NIL.
There is no guarantee that any state implicit in the invocation of the
form (<next-fn>) will survive outside the scope of the WITH-... form.
Test-case:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-ht-generator-test (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-pk-generator-test (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package 'do-symbols)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh.
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
∂07-Oct-88 0650 CL-Cleanup-mailer Re: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 06:50:50 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 7 Oct 88 09:47:09 EDT
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
Subject: Re: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
In-reply-to: Your message of Thu, 06 Oct 88 19:59:09 -0700.
<8810070259.AA07175@bhopal>
Date: Fri, 07 Oct 88 09:46:18 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
Jonl,
Since Lucid has this running, can you comment (or get someone there to
comment) on the accuracy of Chris's guess that it shouldn't be too hard to
implement this? In your implementation, does the outer print communicate
with the inner one by some set of special variables that are visible across
the invocation of the user's structure-printing function? Do you know of
any "gotchas" that have to be addressed in the proposal -- odd interactions
between circle printing and things the user might do in his unrestricted
print function, for example? I'd feel a lot better about this proposal if
we had some real experience to base it on (and maybe even some example
implementation code to copy).
-- Scott
∂07-Oct-88 0743 CL-Cleanup-mailer Issue FIXNUM-NON-PORTABLE (Version 3)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 07:43:06 PDT
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Fri, 7 Oct 88 10:42:59 EDT
Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 7 Oct 88 10:39:56 EDT
Date: Fri, 7 Oct 88 10:40 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: Issue FIXNUM-NON-PORTABLE (Version 3)
To: cl-cleanup@sail.stanford.edu
Cc: x3j13@sail.stanford.edu, Masinter.pa@xerox.com
In-Reply-To: <881006-210851-2113@Xerox>
Message-Id: <19881007144039.0.BARMAR@OCCAM.THINK.COM>
Date: 6 Oct 88 21:08 PDT
From: masinter.pa@xerox.com
Proposal: FIXNUM-NONPORTABLE:TIGHTEN-DEFINITION
(2) remove the type BIGNUM from the language.
I don't really see the point of this. Isn't BIGNUM simply defined to be
(AND INTEGER (NOT FIXNUM))? I admit that it isn't an extremely useful
type specifier, but it is just as portable as FIXNUM.
barmar
∂07-Oct-88 0836 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:36:10 PDT
Received: by ti.com id AA27268; Fri, 7 Oct 88 10:33:59 CDT
Received: from Kelvin by tilde id AA16391; Fri, 7 Oct 88 10:18:44 CDT
Message-Id: <2801229485-95529@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 7 Oct 88 10:18:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: CL-Cleanup@SAIL.Stanford.edu, Bartley@MIPS.csc.ti.com
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
In-Reply-To: Msg of Wed, 5 Oct 88 14:18 EDT from Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
> Just inferred. Why?
I just wanted to see something a little more specific than "CLtL says".
> > Proposal (TAIL-RECURSION-OPTIMIZATION:PERMIT-EARLY-BINDING):
> >
> > Permit early binding in some situations, but do not require them.
>
> This doesn't define what "early binding" means. The test cases suggest
> what the intent is, but I'm not comfortable with specification by
> example.
>
> Can you suggest a wording?
I'm still not clear on what you intended, but here's a minimal
specification that I could support:
Within the body of a DEFUN, if the CAR of a function call form is the
same as the name of the DEFUN, and that name has not been locally
shadowed by an FLET or MACROLET within the DEFUN, then a compiler is
free to assume that the reference is to the current function object
without requiring a run-time lookup of the symbol's function
definition.
You might want to extend this to a self-reference in a FUNCTION form,
but that is less interesting for optimization and causes the auto-load
example to be a problem.
> In particular, it isn't clear whether you intend to affect the
> case of one function calling another, or if you are only talking about
> functions that reference their own definition.
>
> I see no reason to distinguish. Do you agree? If not, can you please make
> a case for why a function referencing itself should be different than a
> function referencing another function.
No, I don't agree. In the case of a function that references itself,
there can only be an inconsistency if the function is redefined during
execution of the function, which is not very likely. However, when
calling another function, one would have to presume the possibility that
the other function will be changed before the current function is
changed.
> This is the kind of thing I worry
> about:
> (SETQ FACT '(LAMBDA (X) (COND ((ZEROP X) 1) (T (* X (FACT (- X 1)))))))
> (COMPILE 'FACT FACT)
> vs (SETF (SYMBOL-FUNCTION 'FACT) (COMPILE NIL FACT)).
> Any difference in behavior/efficiency of these two forms would seem
> highly gratuitous to me.
But how can any optimization be done in the second case, where the call
to FACT is referencing a function that isn't defined at the time of
compilation?
∂07-Oct-88 0848 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 08:48:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472524; Fri 7-Oct-88 11:46:48 EDT
Date: Fri, 7 Oct 88 11:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, CL-Cleanup@SAIL.Stanford.edu,
Bartley@MIPS.csc.ti.com
In-Reply-To: <2801229485-95529@Kelvin>
Message-ID: <19881007154627.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 7 Oct 88 10:18:05 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
In the case of a function that references itself,
there can only be an inconsistency if the function is redefined during
execution of the function, which is not very likely.
That's not true, because a function can't reference -itself-, it can
only reference -its name-. For example,
(defun foo (x)
(if (zerop x) 1 (* x (foo (1- x)))))
(setf (symbol-function 'bar) (symbol-function 'foo))
(defun foo (x)
(* x 2))
(bar 3) => 12, not 6
∂07-Oct-88 1020 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 10:19:52 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472589; Fri 7-Oct-88 13:17:45 EDT
Date: Fri, 7 Oct 88 13:17 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810070517.AA07620@bhopal>
Message-ID: <19881007171716.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
This is a good issue to address, but I can't figure
out what you're actually proposing. The single paragraph
under "proposal" says only that the default for the :use argument
to MAKE-PACKAGE should be implementation-dependent, but the
rest of the message acts as if you had proposed something much
more concrete. I don't see how any implementation could be
said not to implement such a proposal!
Had you intended to propose something specific about the value of
(package-use-list "USER")? Had you intended to propose something
specific about the default for the :use argument to MAKE-PACKAGE? Had
you intended to propose that these must be equal?
∂07-Oct-88 1102 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 11:02:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472615; Fri 7-Oct-88 14:00:33 EDT
Date: Fri, 7 Oct 88 14:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810070714.AA07902@bhopal>
Message-ID: <19881007180006.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor this for the most part, but it needs some corrections.
I hope you get this mail before Monday, as I won't be at the meeting.
There is no guarantee that any state implicit in the invocation of the
form (<next-fn>) will survive outside the scope of the WITH-... form.
The word "scope" here is a typo for "extent". In addition, it's hard to
figure out what this means, since it does not use the standard
terminology for describing exceptions. Why not say, "It is an error to
evaluate the form (<next-fn>) outside the dynamic extent of the body of
the WITH-... form"?
Clarify that <hash-table>, <package>, and <type> are only evaluated once.
The phrase `a boolean to indicate no more entries (T says "there are more")'
used in the description of the first value of the generator can be
interpreted ambiguously. The example makes it clear that the value returned
for the last hash-table or package entry is T, but a reader could think
that the intention was that NIL is returned with the last entry. Perhaps
this could be rephrased in terms of the validity of the second and third
values? Or in words such as "it either returns T and an entry, or NIL
when all entries have already been returned."
The syntax of WITH-PACKAGE-ITERATOR is rather baroque. It has an optional
subform (<package>) preceding a required subform (<type>), and it uses
non-keyword symbols as flags, of which three are in the LISP package and
two are not. Here's a possible alternative that I think is cleaner:
WITH-PACKAGE-ITERATOR ((<next-fn> <type> &optional <package>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that each invocation (<next-fn>) will return
the successive items from the package which is the value of the
expression <package>. Iterating over such a form will thus make the
contents of the package available one at a time. The <type> argument
may assume any of the following values, indicating the sort of
symbols wanted:
:ACCESSIBLE ;all symbols present or inherited
:PRESENT ;all symbols present in the package
:EXTERNAL ;all symbols exported by the package
:INTERNAL ;all symbols present and not exported
:ALL ;all symbols in all packages
<package> is required unless <type> evaluates to :ALL, then <package>
can be omitted.
One could debate the set of types provided, e.g. removing :INTERNAL
or adding :INHERITED. I don't care about that.
∂07-Oct-88 1106 CL-Cleanup-mailer Issue: PATHNAME-WILD (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 11:06:09 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472618; Fri 7-Oct-88 14:04:44 EDT
Date: Fri, 7 Oct 88 14:04 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PATHNAME-WILD (Version 2)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <881006215027.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19881007180424.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
PATHNAME-WILD:NEW-FUNCTION looks good to me.
∂07-Oct-88 1115 CL-Cleanup-mailer SUBTYPEP-TOO-VAGUE, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 11:15:36 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472623; Fri 7-Oct-88 14:13:57 EDT
Date: Fri, 7 Oct 88 14:13 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SUBTYPEP-TOO-VAGUE, version 3
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881006-163656-1686@Xerox>
Message-ID: <19881007181338.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
SUBTYPEP-TOO-VAGUE:CLARIFY looks good to me.
Since some implementations might use the prohibited words internally
in implementation of built-in types, for example,
(deftype simple-array (&optional element-type dimensions)
`(and (array ,element-type ,dimensions)
(satisfies simple-array-p)))
I think you need to say explicitly that subtypep cannot return a second
value of nil when both arguments involve only the words in Table 4-1, or
names of defstruct- or defclass-defined types, or user-defined deftypes
that expand into only those words and/or names.
I think you're right that the rules for comparing the various type
specifiers could usefully be spelled out in detail. Maybe some ad hoc
committee to do just that should be set up?
∂07-Oct-88 1144 CL-Cleanup-mailer Issue: EXIT-EXTENT (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 11:44:15 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472637; Fri 7-Oct-88 14:42:51 EDT
Date: Fri, 7 Oct 88 14:42 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: EXIT-EXTENT (Version 3)
To: CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: <881001-160630-2212@Xerox>
Message-ID: <19881007184224.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: 1 Oct 88 16:06 PDT
From: masinter.pa@Xerox.COM
Sigh, I started to edit this....but I'm afraid it needs more work
than I have time for right now.
Okay, here's a revision with some wording changes. I included most of
your edits, except for a few that simply messed up the formatting and
one that was based on a misunderstanding. I've made the terminology
definitions much more explicit, and I hope much clearer.
Issue: EXIT-EXTENT
References: CATCH, THROW,
BLOCK, RETURN, RETURN-FROM,
TAGBODY, GO, UNWIND-PROTECT,
Dynamic extent (CLtL p.37),
Nested dynamic extents (CLtL p.38),
Blocks can only be exited once (CLtL p.120),
Catch is disestablished just before the values
are returned (CLtL p.139).
Cleanup issue UNWIND-PROTECT-NON-LOCAL-EXIT is superseded
by this one.
Category: CLARIFICATION
Edit history: Version 1, 5-Sep-88, by Moon, for discussion
Version 2, 1-Oct-88, by Masinter, minor edits
Version 3, 7-Oct-88, by Moon, wording improvements
Problem description:
CLtL does not specify precisely when the dynamic extent (lifetime)
of a nonlocal exit such as a CATCH, BLOCK, or TAGBODY ends.
There are three cases of interest:
(1) Normal exit from a CATCH, BLOCK, or TAGBODY, or equivalent such as
PROG. A normal exit occurs when the last form in the body of one of
these constructs completes its evaluation without performing a transfer
of control. (According to CLtL p.125, there is no possibility of a
normal exit from DO.)
(2) Nonlocal exit from the target of a THROW or RETURN. A nonlocal exit
occurs when control is transferred by THROW, RETURN, or RETURN-FROM.
The CATCH or BLOCK named in the THROW, RETURN, or RETURN-FROM is
referred to as the target. The TAGBODY containing the tag named by a
GO is also referred to as the target, but GO differs from the other
nonlocal control transfer operators because GO does not exit its target.
(3) Abandonment of an exit passed over by THROW, RETURN, or GO. A
CATCH, BLOCK, or TAGBODY that is dynamically nested inside the target of
a nonlocal transfer of control is said to be passed over when control is
transferred to the target. The target itself is not said to be passed
over.
The terms "normal exit", "target", and "passed over" will be used with
these meanings for the remainder of the discussion.
CLtL is unambiguous about case 1. In case 2, the extent could end
anywhere from the time the THROW or RETURN commences, until the time the
transfer of control is completed. In case 3, the extent could end
anywhere from the time the THROW, RETURN, or GO commences, until the
time the transfer of control is completed. In case 2, it is clear that
the extent of the target ends before the transfer of control completes,
since a block cannot be exited twice, but it is not made clear whether
the extent ends before or after execution of UNWIND-PROTECT cleanup
forms. CLtL says nothing about case 3, although a note on p.38 implies
that the extent of a passed-over exit should end no later than the end
of the extent of the target exit. It would make sense for the extent
of an exit passed-over by GO to end no later than when the transfer of
control is completed, but CLtL says nothing about this.
Proposal (EXIT-EXTENT:MINIMAL):
The dynamic extent of an exit, whether target or passed-over, ends as
soon as the THROW, RETURN, or GO commences. In the language of the
implementation note on p.142, the extent ends at the beginning of the
second pass. It is an error for an UNWIND-PROTECT cleanup form executed
during a nonlocal transfer of control to attempt to use an exit whose
dynamic extent ended when the nonlocal transfer of control commenced.
This proposal is called "minimal" because it gives exits the smallest
extent consistent with CLtL.
Test Cases/Examples:
Each of the following programs is an error:
(funcall (block nil #'(lambda () (return)))) ;case 1
(block nil ;case 2
(unwind-protect (return)
(return)))
(block a ;case 3
(block b
(unwind-protect (return-from a)
(return-from b))))
(let ((a nil)) ;case 1
(tagbody t (setq a #'(lambda () (go t))))
(funcall a))
(funcall (block nil ;case 3
(tagbody a (return #'(lambda () (go a))))))
(catch nil ;case 2
(unwind-protect (throw nil t)
(throw nil t)))
(catch 'a ;case 3
(catch 'b
(unwind-protect (throw 'a t)
(throw 'b t))))
The above program is an error because the catch of b is passed over by
the first throw, hence portable programs must assume its dynamic extent
is terminated. The catch is not yet disestablished and therefore it
is the target of the second throw.
The following program is not an error. It returns 10. The inner
catch of a is passed over, but this is not case 3 because that catch
is disestablished before the throw to a is executed.
(catch 'a
(catch 'b
(unwind-protect (1+ (catch 'a (throw 'b 1)))
(throw 'a 10))))
Rationale:
Giving exits the smallest extent consistent with CLtL maximizes freedom
for implementations; there are few applications, if any, that require a
longer extent.
Current practice:
Both implementations of Symbolics Genera (3600 and Ivory) end the extent
of a target block or catch at the moment the values are returned, and
end the extent of a passed-over exit at the moment the THROW, RETURN, or
GO commences. This choice of extent maximizes efficiency within the
particular stack structure used by these implementations, by avoiding
the need to retain the control information needed to use a passed over
exit through the transfer of control. Genera signals an error if an
attempt is made to use an exit that has been passed over.
In some implementations, the extent of a target exit lasts until the
exit has been completed; in those implementations, it is possible for a
throw or non-local exit to be effectively "stopped" by an UNWIND-PROTECT
cleanup clause that performs a nonlocal transfer of control to a
passed-over exit.
Cost to Implementors:
No currently valid implementation will be made invalid by this proposal.
Some implementors may wish to add error checks if they do not already
have them.
Cost to Users:
Since this is a clarification and current implementations differ, this
issue ostensibly does not affect current portable programs.
Cost of non-adoption:
The semantics of exits will remain ambiguous.
Benefits:
Common Lisp will be more precisely defined, and the precise definition
will be consistent with current practice in a way that has no cost for
implementors nor for users.
Esthetics:
Precisely specifying the meaning of dynamic extent improves the language.
Leaving implementations free to implement a longer extent if they choose
can be regarded as unesthetic, but consistent with Common Lisp philosophy.
Having a CATCH that is in scope even though its extent has ended may
seem unesthetic, but it is consistent with how BLOCK behaves.
Discussion:
One aspect of this issue, namely the particular behavior of non-local
exits from unwind protect cleanup clauses, was discussed at great
length. Some of that discussion centered around the possibility of
creating "unstoppable loops" that could not be exited, by constructs
like
(tagbody retry (unwind-protect .... (go retry)))
The goal of this proposal is to clarify the ambiguity in CLtL while
minimizing changes to the current situation. An alternative proposal
would define the extent of an exit to end at the last moment possible
within some particular reference implementation. That alternative would
have a cost to implementors whose implementation is not identical to the
reference implementation. Another alternative proposal would duck the
issue by outlawing all nonlocal exits from UNWIND-PROTECT cleanup forms.
That alternative would have a substantial cost to some users.
Scheme is cleaner: it avoids this issue by specifying that the extent
of an exit never ends.
CLtL never says in what dynamic environment cleanup forms of
UNWIND-PROTECT are executed. The implementation note on p.142 may have
been intended to cover this, but since it doesn't define the term
"frame" that it uses, it doesn't actually say anything. The extent of
dynamic-extent entities other than exits should be the
subject of a separate proposal.
∂07-Oct-88 1212 CL-Cleanup-mailer several hundred ugly things
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 12:12:30 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00391g; Fri, 7 Oct 88 12:11:02 PDT
Received: by bhopal id AA01126g; Fri, 7 Oct 88 12:09:20 PDT
Date: Fri, 7 Oct 88 12:09:20 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810071909.AA01126@bhopal>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Thu, 06 Oct 88 20:51:36 EDT <8810070057.AA00831@lucid.com>
Subject: several hundred ugly things
... You develop your program using whatever parts of the full
language you need, then compile in a way that trims away anything that
wasn't used. This creates a subset of Common Lisp that exactly fits the
needs of the application in question. A simple version of this is trivial
to implement in any system that has a copying GC; ...
If only that were true. For example, a routine that uses + implicitly
uses bignums and complex numbers, plus ERROR to handle problems like
(+ 'a '(foo)). Bignums require GC. ERROR uses FORMAT, READ, and
EVAL. FORMAT uses..., and pretty soon you've got the kitchen sink
again. Lucid has devoted a lot of effort over the last year or so to
the goal of making small delivery images. We've learned a lot and made
considerable progress, but because of issues like the above, the task
was unfortunately far from trivial.
Perhaps another way to state the problem is that defining "fits the
needs of the application" for arbitrary applications is a knowledge-
intensive (i.e. difficult) task.
On the other hand, if you meant by "simple" that ERROR terminates
lisp, bignums aren't allowed, etc., then I guess I can't quibble.
jlm
∂07-Oct-88 1222 CL-Cleanup-mailer Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 12:22:32 PDT
Received: by ti.com id AA28753; Fri, 7 Oct 88 14:20:05 CDT
Received: from Kelvin by tilde id AA21104; Fri, 7 Oct 88 14:02:13 CDT
Message-Id: <2801242938-903828@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Fri, 7 Oct 88 14:02:18 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>,
CL-Cleanup@SAIL.Stanford.edu, Bartley@MIPS.csc.ti.com
Subject: Re: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
In-Reply-To: Msg of Fri, 7 Oct 88 11:46 EDT from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> That's not true, because a function can't reference -itself-, it can
> only reference -its name-. For example,
>
> (defun foo (x)
> (if (zerop x) 1 (* x (foo (1- x)))))
> (setf (symbol-function 'bar) (symbol-function 'foo))
> (defun foo (x)
> (* x 2))
> (bar 3) => 12, not 6
Good point; this example helps clarify the issue: is this the behavior
desired? I think not, since when the programmer wrote the DEFUN for FOO
he most likely intended that the call to FOO referred to the function
he was defining, not to some other FOO that might be defined later.
Thus, in this case, early binding would cause less surprise than late
binding.
∂07-Oct-88 1222 CL-Compiler-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 12:22:17 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472680; Fri 7-Oct-88 15:16:45 EDT
Date: Fri, 7 Oct 88 15:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Eric Benson <eb@lucid.com>, cl-compiler@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: <8810040400.AA13928@defun.utah.edu>
Message-ID: <19881007191607.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 3 Oct 88 22:00:24 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....
If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment.
Yes, in EB's proposal AUGMENT-ENVIRONMENT needs a :REMOTE argument
which defaults to the remoteness of the ENV argument and specifies
the remoteness of the returned environment.
One other thing I would like clarified. It makes sense to be able to
have more than one distinct remote environment around at any given
time; for example, if COMPILE-FILE is called recursively it ought to
create a new remote environment for each file.
That's true, although I was refraining from proposing anything that
complicated. If we get into that, then we also will have to make
environments extensible as I think I mentioned before. But if we
confine ourselves to just putting in a way to tell whether this is a
remote environment or not, that will be enough to get CLOS off the
ground.
Does it make any sense
to have more than one distinct local environment around, or is there
only one?
There is only one local global environment (gnashing of teeth in the
background over the terminology) in Common Lisp, but there can be more
than one in some dialects of Scheme (they're called "locales").
Multiple local global environments seem like a sound approach to solving
the same problems that packages were invented to solve.
On the terminology, this shows that "remote" is an okay word, but we
shouldn't use "local" as the antonym of "remote", since "local" is already
used as the antonym of "global". How about "running"?
I can imagine that a Lisp running on a non-shared-memory
parallel machine might want to maintain separate local environments on
each processor, for instance.
No, I think you're confused here. Environments have to do with the
mapping of names to objects (and to conceptual objects such as BLOCKs
and GO tags). I don't think this has anything to do with addressing
memory, local or global, shared or non-shared. I'm not sure what your
vision of a Lisp on a non-shared-memory parallel machine is, but I
suspect I would call it several independent Lisps talking to each other
through some communication medium. In that sense there are multiple
local environments, since each Lisp has its own, but since the Lisps
don't share objects, this isn't an interesting distinction in the way
that the local/remote environment distinction in COMPILE-FILE is
interesting.
∂07-Oct-88 1305 CL-Cleanup-mailer PRINT-CIRCLE-STRUCTURE
Received: from A.GP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 13:04:37 PDT
Date: Fri Oct 7 15:50:41 1988
From: Christopher.McConnell@A.GP.CS.CMU.EDU
To: cl-cleanup@sail.stanford.edu
Subject: PRINT-CIRCLE-STRUCTURE
I have updated the proposal based on feedback from Dave Touretzky,
Scott Fahlman, Jon White, David Moon and Kent Pitman.
Issue: PRINT-CIRCLE-STRUCTURE
References: pp. 370-371
Category: CLARIFICATION
Edit history: Version 1.1, Chris McConnell 10/05/88
Version 1.0, Chris McConnell 09/20/88
Problem description:
When a lisp object is printed that points to a structure with a user
defined print-function and there is a pointer back to the containing
object, the printer will recurse infinitely even when *print-circle*
is set to T. This prevents printing circular structures that point to
objects that cannot be printed and prevents the development of new
printed representations that can be read by the reader.
Proposal PRINT-CIRCLE-STRUCTURE:
When *print-circle* is T, a user defined print-function can print
objects to the supplied stream using WRITE, PRIN1, PRINC, or FORMAT
and expect circularities to be detected and printed using #n# syntax.
If a user defined print-function prints to a stream other than the one
that was supplied, then circularity detection starts over for that
stream.
Test Cases/Examples:
;;;
;;; Define a structure that can be circular and that has a slot with a
;;; value that cannot be printed.
;;;
(defstruct (TEST (:print-function print-test))
ptr
(function #'(lambda (x)
(error "No function is defined."))))
;;;
;;; This print function generates a machine readable printed
;;; representation for a structure with a slot that cannot be printed.
;;;
(defun PRINT-TEST (structure stream depth)
(format stream "#S(TEST PTR ~S)" (test-ptr structure)))
;;;
;;; Define two structures that point to each other. If this
;;; expression successfully evaluates at the top level, then the
;;; printed result should look like:
;;; #1=#S(TEST PTR #S(TEST PTR #1#))
;;;
;;; If it does not work then it will generate an infinite printed
;;; representation.
(setf *print-circle* t
*a (make-test)
*b (make-test)
(test-ptr *a) *b
(test-ptr *b) *a)
Rationale:
Many structures are circular and point to complex data structures that
may include things like closures that cannot be printed. It should be
possible to define a way to print these data structures such that they
can be read back in. Common LISP provides two mechanisms for these
problems (*print-circle* and the :print-function option to defstruct),
but they do not currently work together in most implementations.
Current practice:
Lucid 3.0 and the Genera do work on the test case. (Previous versions
did not.) KCL, Coral and Franz do not work.
Cost to Implementors:
Lucid and Symbolics have done it, so they could give an idea of the
difficulty. Possible techniques include passing the printer state
information by dynamic binding rather than by explicit parameters or
by supplying an internal stream to the user print function.
Cost to Users: None
Cost of non-adoption:
Currently this problem causes an infinite recursion whenever a user
print-function prints a lisp object that contains the structure that
is being printed by the user print function. If nothing is done, this
error will remain and the whole effort to provide a portable printed
representation of LISP structures is of minimal usefulness. In almost
any real application, there are circular structures with non printable
objects such as closures and hash tables that need to be printed. In
addition the development of printers for new reader macros becomes
much more of an effort then it should be since it requires
reimplementing the complete circularity detection mechanism.
Benefits:
If the proposal is adopted, then it becomes easier to define new
printed representations that are compact and that still capture the
information needed to rebuild data structure instances. It allows a
printed representation to hide the actual details of how a data
structure is implemented in terms of underlying LISP data structures.
Esthetics:
This proposal increases the uniformity of the language by making
*print-circle* work in all cases including where a user has defined a
new print function.
Discussion:
∂07-Oct-88 1418 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 7 Oct 88 14:18:18 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA04912; Fri, 7 Oct 88 17:17:38 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA03303; Fri, 7 Oct 88 17:19:24 EDT
Message-Id: <8810072119.AA03303@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Date: Fri, 07 Oct 88 17:19:22 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
References: Array type specifiers, pp. 45-46
Related issues: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, DECLARE-TYPE-FREE
Category: CLARIFICATION
Edit history: Version 1, 7-Oct-88, Pierson
Problem description:
Array type specifiers appear to be useful both for declaring the
storage format of the array and for declaring the types of legal
operations on array elements. Unfortunately, the current definition
of the meaning of array type specifiers does not require an
implementation to support the second use.
Proposal (DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES:RESTRICTIVE):
Within the scope of an array type declaration, all references to array
elements are assumed to satisfy the exact declared element type. An
implementation should signal an error if this is ever violated. A
compiler may treat the code within the scope of the array type
declaration as if each access of an array element was surrounded by an
appropriate THE form.
Examples:
(DEFVAR *ONE-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 5)))
(DEFVAR *ANOTHER-ARRAY* (MAKE-ARRAY 10 :ELEMENT-TYPE '(SIGNED-BYTE 8)))
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (AREF AN-ARRAY 1) 31) ; OK
(SETF (AREF AN-ARRAY 2) 127) ; Should signal an error
(SETF (AREF AN-ARRAY 3) (* 2 (AREF AN-ARRAY 3))) ; Run-time decision needed
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (AREF AN-ARRAY 0)))) ; Declared to be safe
(FROB *ONE-ARRAY*) ; Legal call, should signal an error
(FROM *ANOTHER-ARRAY*) ; Is probably an undetectable error
Note that the above definition of FROB is equivalent to:
(DEFUN FROB (AN-ARRAY)
(DECLARE (TYPE (ARRAY (SIGNED-BYTE 5) 1) AN-ARRAY))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 1) 31))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 2) 127))
(SETF (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))
(* 2 (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 3))))
(LET ((FOO 0))
(DECLARE (TYPE (SIGNED-BYTE 5) FOO))
(SETF FOO (THE (SIGNED-BYTE 5) (AREF AN-ARRAY 0)))))
Test Cases:
TBS
Rationale:
This mandates a useful and commonly expected behavior. It complements
proposal ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, which deals with array
type specifiers as they refer to arrays as a whole. The "should
signal an error" requirement permits compiler optimization while
requiring interpreters and low compiler optimization levels to perform
useful error checking.
Current practice:
???
Cost to Implementors:
Most implementations will have to extend the type checking in the
interpreter and low optimization levels of the compiler.
Cost to Users:
Some users might find that errors in existing code become visible for
the first time.
Cost of non-adoption:
Users will continue to expect declaration syntax to be more useful
than it really is.
It will be harder to debug code that uses arrays containing
specialized types.
Performance impact:
Highly optimized code should be unaffected. Interpreted and
unoptimized code will run slower because of the additional error
checking.
Benefits:
It will be easier to use the Common Lisp type system to catch
programming errors.
Aesthetics:
Improved because the meaning of type declarations will coincide more
clearly with their appearance.
Discussion:
Pierson supports this proposal.
JonL expressed support for the idea behind this proposal during the
discussion of ARRAY-TYPE-ELEMENT-TYPE-SEMANITICS but said that it was
a compiler committee problem. This was submitted as a cleanup issue
anyway because it imposes requirements on the interpreter as well as
the compiler.
∂07-Oct-88 1501 CL-Cleanup-mailer Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:00:54 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 14:38:38 PDT
Date: 7 Oct 88 14:35 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: HASH-TABLE-PRINTED-REPRESENTATION (Version 1)
In-reply-to: your message of Sat, 17 Sep 88 06:45:07 EDT
To: Dave.Touretzky@B.GP.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881007-143838-1095@Xerox>
Its almost too late to do anything about it, but I had misfiled the
following message about HASH-TABLE-PRINTED-REPRESENTATION. My only excuse
is that there are 104 pending issues.
If you have or want to make a revision to your proposal, which I will
include, and can get to it *today*, let me know. Otherwise, this will wait
for the next meeting or a letter ballot or something.
Included is a message from JonL about HASH-TABLE-PRINTED-REPRESENTATION and
the last version of it.
!
Return-Path: <edsel!jonl@labrea.stanford.edu>
Received: from labrea.stanford.edu by Xerox.COM ; 09 JUN 88 21:36:17 PDT
Received: by labrea.stanford.edu; Thu, 9 Jun 88 21:35:32 PDT
Received: from bhopal.lucid.com by edsel id AA18027g; Thu, 9 Jun 88
21:27:54 PDT
Received: by bhopal id AA26522g; Thu, 9 Jun 88 21:26:35 PDT
Date: Thu, 9 Jun 88 21:26:35 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
Message-Id: <8806100426.AA26522@bhopal.lucid.com>
To: masinter.pa
Cc: X3J13@sail.stanford.edu, cl-cleanup@sail.stanford.edu
In-Reply-To: Masinter.pa@Xerox.COM's message of 8 Jun 88 20:24 PDT
<880608-202925-3823@Xerox>
Subject: Issue: HASH-TABLE-PRINTED-REPRESENTATION
Touretzky actually said he would alter his proposal to account for the
:rehash-size and :rehash-threshold omissions; but this version of the
proposaldoesn't show that. I remember remarking that you still can't
call the objects "first class" if the printed representation cannot be
read in as an equivalent copy; and the fact that CL has some other
datatypes
that aren't "first class" doesn't argue for doing something substandard
for hash-tables. I don't seem to have a copy of the mail from Dave in
which he said he would alter his proposal.
Date: Mon, 23 May 88 15:37:48 PDT
From: Jon L White <edsel!jonl@labrea.stanford.edu>
To: labrea!Dave.Touretzky@CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Mon, 23 May 88
11:27:58 EDT <361.580404478@DST.BOLTZ.CS.CMU.EDU>
Subject: HASH-TABLE-PRINTED-REPRESENTATION
re: One problem with the currently proposed #H notation is that it
provides
no way to specify a rehash-size or rehash-threshold. This should not
be
a fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when
the
element-type is something more specific than T. The latter problem
is
also shared by #nA notation.
I think this is a fatal flaw. The fact that *some* complex classes of
arrays also share this fatal flaw is no argument for retaining it. It
is still the case that simple arrays of the more common element types
do not have the flaw; and several years ago there was some discussion
on how to fix other manifestations of the flaw on multi-dimensional
arrays.
-- JonL --
!
Status: DRAFT
Issue: HASH-TABLE-PRINTED-PREPRESENTATION
Category: ENHANCEMENT
Edit history: 23-May-88, Version 1 by Touretzky
8-Jun-88, Version 2 by Masinter (as per cl-cleanup discussion)
Description:
Hash tables are currently second-class data structures when compared to
lists, vectors, and structures, because they have no READable printed
representation. This proposal introduces a #H reader syntax for hash
tables and a switch to control when hash tables will be printed this way.
Proposal (HASH-TABLES-PRINTED-REPRESENTATION:#H-NOTATION) :
1) Introduce the following reader notation for hash tables:
#nH(type (k1 v1) (k2 v2) ...)
"n" is the size of the table; it is analagous to the :size argument to
MAKE-HASH-TABLE. If omitted, the system picks some reasonable size.
"type" is one of EQ, EQL, or EQUAL. If omitted it defaults to EQL.
The (ki vi) pairs consist of a key and a value. There may be any number
of
such pairs, including zero. Order is not significant. It is an error
for
two keys to be identical (using the EQ, EQL, or EQUAL test, as
appropriate.)
2) Introduce a switch called *PRINT-HASH* whose initial value is
implementation-dependent. If *PRINT-HASH* is T, hash tables are printed
using the #H syntax (with all optional components supplied), subject to the
usual limits imposed by *PRINT-LEVEL* and *PRINT-LENGTH*. If *PRINT-HASH*
is NIL, hash tables are printed using the current #<HASH-TABLE ...> syntax.
Rationale:
This is a useful upward compatible extension (except in
implementations that have usurped #H for other purposes), with very
low adoption cost.
Cost to Implementors:
A simple change to PRIN1 and the pretty printer. Most of the code
will be similar to existing routines for printing vectors in #()
notation and arrays in #nA() notation. The reader would change to
read this notation.
Cost to Users:
Small. Programs that want to control all *PRINT- parameters will need
to know about yet another parameter.
Benefits:
This proposal makes hash tables first class objects. If
*PRINT-HASH* is T, their contents become visible in all the normal ways,
e.g., if FOO is bound to a hash table object, then typing FOO to a
read-eval-print loop will display the contents of the hash table. Hash
table contents may also be displayed by TRACE if the table is passed as an
argument; they may also be displayed by the debugger. Finally, hash tables
may be appear as literal objects in programs and be read or written to
files.
Current practice:
We know of no current implementations of this proposal.
Although some implementations allow the user to see hash table contents
with DESCRIBE or INSPECT, not all do. CMU Common Lisp's DESCRIBE, for
example, does not show hash table contents. This reinforces the need for
a standard #H notation to guarantee that users can manipulate a hash table
as easily as a vector, array, or structure.
Discussion:
Several alternatives have been suggested for the syntax of #H.
- preferred notation: #H(EQL (FOO 37) (BAR 42))
- dotted pair notation: #H(EQL (FOO . 37) (BAR . 42))
- property list: #H(EQL FOO 37 BAR 42)
- pseudo-structure: #S(HASH-TABLE TYPE EQL SIZE 20 INITIAL-CONTENTS
((FOO 37) (BAR 42)))
One problem with the currently proposed #H notation is that it provides no
way to specify a rehash-size or rehash-threshold. This should not be a
fatal flaw, though. The #() notation is also incomplete: it cannot
indicate whether the vector has a fill pointer, nor can it show when the
element-type is something more specific than T. The latter problem is also
shared by #nA notation. Some object that the fact that #A is flawed is no
reason to introduce the same flaw elsewhere.
This prompted yet another proposal:
#[size]H([type] [rehash-size] [rehash-threshold] (ki vi)*)
e.g. #65H(EQL 101 65 (FOO 37) (BAR 42))
along with alternative settings for *PRINT-HASH*, NIL, T, :BRIEF, where the
latter would leave out all of the options.
∂07-Oct-88 1528 CL-Cleanup-mailer Issue: DEFPACKAGE (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:28:43 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00777g; Fri, 7 Oct 88 15:27:21 PDT
Received: by bhopal id AA01833g; Fri, 7 Oct 88 15:25:41 PDT
Date: Fri, 7 Oct 88 15:25:41 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810072225.AA01833@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@Sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 00:12 EDT <19881007041242.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: DEFPACKAGE (version 5)
I approve of this version.
I also like :internal, and had intended to bring it up before. The comment
about uselessness:
- the change to :IMPORT-FROM and :SHADOWING-IMPORT-FROM to call
FIND-SYMBOL instead of INTERN inadvertently made them useless,
since there is no way to assure that non-exported, non-shadowed
symbols exist. . . .
is a bit overly pessimistic here, since internals symbols are created
merely by reading files. But there's no question that defpackage should
have a way of creating internal non-exported, non-shadowing symbols.
-- JonL --
∂07-Oct-88 1556 CL-Cleanup-mailer Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 15:56:18 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472850; Fri 7-Oct-88 18:54:24 EDT
Date: Fri, 7 Oct 88 18:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: pierson%mist@MULTIMAX.ARPA
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810072119.AA03303@mist.UUCP>
Message-ID: <881007185412.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
This is inconsistent with current practice in that implementations are
currently permitted to ignore type declarations altogether -- not just
for array but for anything.
The only consistent proposal would be to say that in all cases where
declarations are done and violated, an implementation should signal an
error -- not just for arrays.
Either way, you're talking major work. Although not technically an
incompatible change, some implementations (like the Lisp machine family)
currently don't track these declarations at all since it would mostly
only slow things down. Some other (stock hardware) implementations
only track the types they know how how to optimize. Eg, they might
ignore SYMBOL declarations because they don't have an optimization that
pertains to symbols but they might track FIXNUM declarations because
they know lots of cool things to do with that.
As such, your cost to implementors seems a little understated. I
do not personally maintain that aspect of any implementation, so I'm
just guessing but it looks to my naive eye like it's not just
a matter of "extended some checking" -- it might also mean some
pretty sweeping changes to the kinds of information that have to
be tracked by interpreters and compilers, and perhaps in some cases
even to the modularity of the interpreter and/or compiler.
∂07-Oct-88 1608 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from multimax.ARPA (MULTIMAX.ENCORE.COM) by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:08:39 PDT
Received: by multimax.ARPA (5.51/25-eef)
id AA05562; Fri, 7 Oct 88 19:08:23 EDT
Received: from localhost by mist.UUCP (3.2/4.7)
id AA03705; Fri, 7 Oct 88 19:10:10 EDT
Message-Id: <8810072310.AA03705@mist.UUCP>
To: cl-cleanup%sail.stanford.edu@multimax
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Date: Fri, 07 Oct 88 19:10:08 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
This is inconsistent with current practice in that implementations are
currently permitted to ignore type declarations altogether -- not just
for array but for anything.
Sorry 'bout that. Would you be happy if it was changed to specify
that implementations which pay attention to type declarations must
treat references to array elements as strictly as any other declared
type?
More globally, with the new error terminology we're going to have to
decide whether implementations will still be permitted to ignore type
declarations for interpreted and unoptimized code. Since these cases
can no longer be "is an error", they've got to become either "should
be signalled", "undefined", or "unspecified". I favor "should be an
error" because type checking can be a powerful debugging tool and some
current users appear to expect it to work as such, look at the CLX
sources for example.
∂07-Oct-88 1616 CL-Cleanup-mailer Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:15:54 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472873; Fri 7-Oct-88 19:13:56 EDT
Date: Fri, 7 Oct 88 19:13 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: DECLARE-ARRAY-TYPE-ELEMENT-REFERENCES
To: pierson%mist@MULTIMAX.ARPA
cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810072306.AA03674@mist.UUCP>
Message-ID: <881007191339.2.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 07 Oct 88 19:06:32 EDT
From: Dan L. Pierson <pierson%mist@multimax.ARPA>
This is inconsistent with current practice in that implementations are
currently permitted to ignore type declarations altogether -- not just
for array but for anything.
Sorry 'bout that. Would you be happy if it was changed to specify
that implementations which pay attention to type declarations must
treat references to array elements as strictly as any other declared
type?
Not really. Any non-conforming implementation could claim to be in the
set of those who don't completely pay attention to declarations.
It's not that I oppose the sentiment. I just don't want to spin our wheels
to no good end. I don't think it takes a formal vote of X3J13 for us to
ask Kathy to add an implementation note to the declartions section that
reminds people that implementations can do such checking and suggests that
they do so where feasible.
To an extent, I think this is the sort of thing that it's appropriate (or
at least -- given all the other things we already have cooking -- necessary)
to let ``market pressure'' take care of.
More globally, with the new error terminology we're going to have to
decide whether implementations will still be permitted to ignore type
declarations for interpreted and unoptimized code. Since these cases
can no longer be "is an error", they've got to become either "should
be signalled", "undefined", or "unspecified". I favor "should be an
error" because type checking can be a powerful debugging tool and some
current users appear to expect it to work as such, look at the CLX
sources for example.
Strictly, there's no decision called for.
"undefined" is the same as "is an error".
I think what you mean to say is now that we have more terms, we might
want to incompatibly change the language so that more things take
advantage of that new terminology.
Put another way, CLtL is unambiguous about the "undefinedness" about
a lot of things, but that lack of ambiguity may not have been intended.
Insofar as numerous such cases are arguably mistakes, and more precise
language may have sometimes been intended (or since been seen to have
been a good idea), it's now time to think about fixing those situations.
If that's what you mean, I agree. But such things are going to be
very expensive at times to do, and we should be honest about the costs
so that implementors can know what they're buying into (or what to
vote against if the cost is prohibitive).
∂07-Oct-88 1640 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:40:48 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00842g; Fri, 7 Oct 88 16:39:32 PDT
Received: by bhopal id AA02095g; Fri, 7 Oct 88 16:37:53 PDT
Date: Fri, 7 Oct 88 16:37:53 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810072337.AA02095@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 14:00 EDT <19881007180006.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
I'll make another version of this proposal before Larry's ultimate deadline;
but first I'd like to see if there are any other reactions to these
comments.
re: There is no guarantee that any state implicit in the invocation of the
form (<next-fn>) will survive outside the scope of the WITH-... form.
The word "scope" here is a typo for "extent". In addition, it's hard to
figure out what this means, since it does not use the standard
terminology for describing exceptions. Why not say, "It is an error to
evaluate the form (<next-fn>) outside the dynamic extent of the body of
the WITH-... form"?
Both "scope" and "extent" are involved here -- the form (<next-fn>) is
defined only within the scope, and any objects which it may create have
validity only within the "extent" of the WITH-... The reason I don't
want to use "It is an error ..." to describe the "extent" constraint
is that the buzz phrase "It is unspecified" (from the "new" error
terminology) is more appropriate here. Implementations which don't use
the Symbolics style "locking" might actually provide indefinite extent
so that the Generators proposal will not be limited.
re: Clarify that <hash-table>, <package>, and <type> are only evaluated once.
Right.
re: The phrase `a boolean to indicate no more entries (T says "there are more")
used in the description of the first value of the generator can be
interpreted ambiguously. ... this could be rephrased ... "it either
returns T and an entry, or NIL when all entries have already been returned"
Sounds good.
re: The syntax of WITH-PACKAGE-ITERATOR is rather baroque. It has an optional
subform (<package>) preceding a required subform (<type>),
Yea, I didn't like that either. An &optional is fine with me; Mlynarik
even suggested &key parameters.
and it uses
non-keyword symbols as flags, of which three are in the LISP package and
two are not. Here's a possible alternative that I think is cleaner:
I used exactly the names of the (extended) CLtL macros for iteration over
packages; e.g.,
(defmacro do-external-symbols ((var &optional pkg result) &body body)
`(with-package-iterator (next ,pkg 'do-external-symbols)
,@body)
The uniformity of implementing the DO-mumble-SYMBOLS seemed like a nice
mnemonic for "flag" choices; unfortunately, it appears that no one ever
submitted the DO-PRESENT-SYMBOLS proposal, so that is why one is not in
the Lisp package. But it's no big thing, so I'll opt for keyword "flags"
if it will help acceptance of the proposal.
re: :ACCESSIBLE ;all symbols present or inherited
:PRESENT ;all symbols present in the package
:EXTERNAL ;all symbols exported by the package
:INTERNAL ;all symbols present and not exported
:ALL ;all symbols in all packages
I might mention that Lucid's implementation has certain optimizations
such that doing the :EXTERNAL case is not at all performance-wise
equivalent to simpely doing the :PRESENT case and filtering out the
internals. Since it just may be that other implmenetations have similar
assymetries about the :INHERITED case, we should add it for completeness.
-- JonL --
∂07-Oct-88 1643 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:42:57 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:30:38 PDT
Date: 7 Oct 88 16:28 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 6 Oct 88 03:16 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Beckerle@XX.LCS.MIT.EDU, Masinter.PA@Xerox.COM, eb@Lucid.COM,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881007-163038-1367@Xerox>
I don't this can be released with such divergent views on what it does.
It would help to talk about the generic capabilities of the type specifiers
independently of their names. I'm not sure that either of the kinds of type
specifiers people want to add make sense, whether you have to have a new
kind of CONS cell or whether it really talks about the old kind.
For discussion on Monday.
∂07-Oct-88 1643 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 2)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 16:42:47 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 16:24:44 PDT
Date: 7 Oct 88 16:24 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 2)
to: cl-cleanup@sail.stanford.edu
Message-ID: <881007-162444-1360@Xerox>
down to the wire, but if you have a chance, you might want to glance at
this before I send it out next time around...
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88
Masinter, Version 2, 7-Oct-88
Problem description:
CLtL allows the redefinition of functions exported from other packages.
Unexperienced programmers may redefine a system function unintentional
which
may result into an inconsistent state of the system and cause to abort.
This
has happened, for example, with a beginner follows an introductory
book where an exercise asks to define a function MAKE-LIST. After the
redefinition of MAKE-LIST the system crashs without returning a message
that the
function has been redefined.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means
that
implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might
refer
to the OPEN function and might not.
(defun car (x) (cdr x))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols
in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition
of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified.
It
allows and encourages implementors to check for such redefinition, but does
not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a
condition
that they might not have before, and may clarify that some current user
code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a
frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones
that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the
"protection"
mechanism to their own macros, functions, packages. These proposals seem
like
they are environment issues and not language ones, however. For example,
you might have a list *REDEFINITIONS-RESTRICTIONS* or
IL:UNSAFE-TO-MODIFY-FUNCTIONS>
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening
out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂07-Oct-88 1702 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:02:22 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00876g; Fri, 7 Oct 88 17:01:07 PDT
Received: by bhopal id AA02168g; Fri, 7 Oct 88 16:59:28 PDT
Date: Fri, 7 Oct 88 16:59:28 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810072359.AA02168@bhopal>
To: CL-Cleanup@SAIL.Stanford.EDU
Subject: Issue: PACKAGE-DELETION (Version 4)
I've added the minor corrections from my note of Wed, 5 Oct 88 17:22:31 PDT,
and changed the Issue name to conform with "cleanup" standards. I also
deleted the "testimonial" (as per Larry's suggestion) since this seems to
be a non-controversial issue.
!
Issue: PACKAGE-DELETION
References: Packages (pp171-192), PACKAGE-NAME (p184), PACKAGEP (p76)
Category: ADDITION
Edit history: 30-Sep-88, Version 1 by Pitman
01-Oct-88, Version 2 by Pitman
04-Oct-88, Version 3 by Pitman
(provide for correctable errors in some cases)
07-Oct-88, Version 4 by JonL
Status: Ready?
Problem Description:
There is no way to get rid of a package in Common Lisp.
This absence makes interactive development work tricky in some
implementations. If a package is accidentally built incorrectly, the
user must either rename the package to another package or start over
by reloading his program in a fresh lisp image.
Some programs need to create and destroy packages at runtime.
Without such a facility, some clumsy combination of RENAME-PACKAGE,
UNINTERN, and UNUSE-PACKAGE is usually made to work. However, it is
easy for a casual programmer to forget to undo some of the
bookkeeping, leading to unwanted effects.
Proposal (PACKAGE-DELETION:NEW-FUNCTION):
Introduce the function DELETE-PACKAGE, described as follows:
DELETE-PACKAGE package [Function]
Deletes PACKAGE from all package system data structures. PACKAGE may
be either a package or the name of a package.
If PACKAGE is a package name (i.e., not type PACKAGE) which does not
currently name a package, a correctable error is signalled. If
continued, no deletion action is attempted. Instead, DELETE-PACKAGE
immediately returns NIL.
If PACKAGE is a package object (i.e., an object of type PACKAGE)
which has already been deleted, no error is signalled and no further
deletion action is attempted. Instead, DELETE-PACKAGE immediately
returns NIL.
If the designated package is used by other packages, a correctable
error is signalled. If continued, the effect of UNUSE-PACKAGE is
done to remove any dependencies, causing its external symbols to stop
being accessible to those packages. Once this is done, DELETE-PACKAGE
goes on to delete the package just as it would had there been no
packages on the use list.
After this operation completes, the contents of the symbol-package
slot of any symbol homed in the deleted package is unspecified; for
those symbols not homed in that package, the contents remain unchanged.
Except for this, symbols in the deleted package are not modified in
any other way.
The principal effect of deleting the package is that the name and
nicknames of the designated package cease to be recognized package
names. The package object is still a package -- PACKAGEP is true
of it -- but PACKAGE-NAME will return NIL. The effect of any other
package operation on PACKAGE once it has been deleted is undefined.
DELETE-PACKAGE returns T if the deletion attempt was successful
and NIL otherwise.
Test Case:
(SETQ *FOO-PACKAGE* (MAKE-PACKAGE "FOO" :USE NIL))
(SETQ *FOO-SYMBOL* (INTERN "FOO" *FOO-PACKAGE*))
(EXPORT *FOO-SYMBOL* *FOO-PACKAGE*)
(SETQ *BAR-PACKAGE* (MAKE-PACKAGE "BAR" :USE '("FOO")))
(SETQ *BAR-SYMBOL* (INTERN "BAR" *BAR-PACKAGE*))
(EXPORT *FOO-SYMBOL* *BAR-PACKAGE*)
(EXPORT *BAR-SYMBOL* *BAR-PACKAGE*)
(SETQ *BAZ-PACKAGE* (MAKE-PACKAGE "BAZ" :USE '("BAR")))
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) => #<Package "BAR">
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) => "BAR:BAR"
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) => FOO:FOO, :EXTERNAL
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => FOO:FOO, :INHERITED
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => BAR:BAR, :INHERITED
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => "BAR"
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) => (#<Package FOO>)
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => (#<Package BAR>)
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) => (#<Package BAZ>)
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
(DELETE-PACKAGE *BAR-PACKAGE*)
Error: Package BAZ uses package BAR.
If continued, BAZ will be made to unuse-package BAR,
and then BAR will be deleted.
Type :CONTINUE to continue.
Debug> :CONTINUE
=> T
(SYMBOL-PACKAGE *FOO-SYMBOL*) => #<Package "FOO">
(SYMBOL-PACKAGE *BAR-SYMBOL*) is unspecified
(PRIN1-TO-STRING *FOO-SYMBOL*) => "FOO:FOO"
(PRIN1-TO-STRING *BAR-SYMBOL*) is unspecified
(FIND-SYMBOL "FOO" *BAR-PACKAGE*) is undefined
(FIND-SYMBOL "FOO" *BAZ-PACKAGE*) => NIL, NIL
(FIND-SYMBOL "BAR" *BAZ-PACKAGE*) => NIL, NIL
(PACKAGEP *FOO-PACKAGE*) => T
(PACKAGEP *BAR-PACKAGE*) => T
(PACKAGEP *BAZ-PACKAGE*) => T
(PACKAGE-NAME *FOO-PACKAGE*) => "FOO"
(PACKAGE-NAME *BAR-PACKAGE*) => NIL
(PACKAGE-NAME *BAZ-PACKAGE*) => "BAZ"
(PACKAGE-USE-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USE-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USE-LIST *BAZ-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *FOO-PACKAGE*) => ()
(PACKAGE-USED-BY-LIST *BAR-PACKAGE*) is undefined
(PACKAGE-USED-BY-LIST *BAZ-PACKAGE*) => ()
Rationale:
This facility corrects the deficiency described in the problem description.
Current Practice:
Symbolics has a function PKG-KILL which satisfies the proposed behavior
except that an error is not signalled if the package is used.
When a package is killed by PKG-KILL, the home package of all symbols
in that package are left undisturbed (i.e., local symbols pointing to
the killed package); this aspect is compatible with the stated proposal.
Procyon Common Lisp has a DELETE-PACKAGE already. It returns the name
of the package so deleted (as a string). [Perhaps it also differs in the
correctability of the errors it signals? -kmp]
Lucid Common Lisp implements DELETE-PACKAGE, except that the continuation
option for a name that doesn't name a package is different.
Cost to Implementors:
The cost of providing this facility is probably small.
Cost to Users:
Very slight to none. This change is essentially compatible.
Some code which cached packages in variables might have to be slightly
more cautious, but experience in the Symbolics implementation suggests
that it's really the responsibility of the person doing the DELETE-PACKAGE
to take care of worrying about the effects of having deleted the package:
normal programs need not bother testing a package for validity (using
PACKAGE-NAME) before using it.
Cost of Non-Adoption:
Getting rid of a package would continue to be difficult to do portably.
Benefits:
Better control of storage usage would be available portably.
Aesthetics:
No significant effect.
Discussion:
This was discussed as part of a larger bulk issue of how to undo all
sorts of definitions. Since that proposal has not gone anywhere
(perhaps bogged down under its own weight), this subtopic has been
broken off for separate discussion.
Note that if a symbol's package component is modified as a result
of being "unintern'd" from a delete packaged, then it is unspecified
as to how it will be printed.
∂07-Oct-88 1732 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:31:34 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00912g; Fri, 7 Oct 88 17:29:56 PDT
Received: by bhopal id AA02294g; Fri, 7 Oct 88 17:28:16 PDT
Date: Fri, 7 Oct 88 17:28:16 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080028.AA02294@bhopal>
To: Scott.Fahlman@B.GP.CS.CMU.EDU
Cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: Scott.Fahlman@B.GP.CS.CMU.EDU's message of Fri, 07 Oct 88 09:46:18 EDT <8810071349.AA01222@lucid.com>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
re: . . . can you comment (or get someone there to
comment) on the accuracy of Chris's guess that it shouldn't be too hard to
implement this? In your implementation, does the outer print communicate
Lucid's circle printer was implemented by someone who left Lucid about
a year ago. About a half-year ago, I diddled with the code, due to a
complaint from a PCL user (it wasn't Chris) who had circular instances.
I spent far more time at it that I wanted to, bolstered by the thoughts:
(1) that with just a little more probing, I'd be able to understand the
opaque algorithms being employed; and
(2) I considered the former behaviour a clear "bug" that was actually
impeding a user's work.
There is no guarantee that all such bugs are fixed now.
Sorry I couldn't be of more help.
-- JonL --
∂07-Oct-88 1738 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:38:13 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472916; Fri 7-Oct-88 20:36:21 EDT
Date: Fri, 7 Oct 88 20:36 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-DELETION (Version 4)
To: jonl@lucid.com
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <8810072359.AA02168@bhopal>
Message-ID: <881007203609.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Grumble.
For the record, I don't really think that
(DELETE-PACKAGE no-such-name)
should be treated the same as
(DELETE-PACKAGE unregistered-package)
In the former case, it is not clear what package you are referring
to, so it's not clear which of several bugs you have:
- The package name might have been mis-spelled.
- The package might have been supposed to exist, but was never loaded/created.
- The package might have already been deleted.
In the latter case, there's only one possibility:
- The package might have already been deleted.
In the case where you're sure you are referring to the correct package
and all you're trying to say is "There is no doubt about the identity
of the package to which I am referring. I would that unambiguously named
package to be inaccessible.", I have no problem about this returning NIL.
In the other case, where any of a number of bugs could have happened,
I'm more comfortable with an error being signalled -- partly for consistency
with your insistance that this function should signal an error rather
than define a useful behavior in the other questionable case: package
already in use. If that didn't cause an error to be signalled, then I
would also not mind quietly returning NIL for the deletion of a package
which does not exist.
I also deliberately did not say that delete package returns T if the
deletion is successful "and otherwise returns NIL" since sometimes it
does not return at all. The usage "and otherwise ..." always implies
and exhaustive case analysis in my mind. The specific cases where NIL
are returned are already cited. I would prefer to just say it returns T
if it was successful and let anyone search the other cases, or else
say something very clumsy like "If DELETE-PACKAGE returns normally,
the value returned is T if the deletion was successful and NIL otherwise."
∂07-Oct-88 1743 CL-Cleanup-mailer Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:43:48 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00881g; Fri, 7 Oct 88 17:03:36 PDT
Site:
Received: by bhopal id AA02180g; Fri, 7 Oct 88 17:01:56 PDT
Date: Fri, 7 Oct 88 17:01:56 PDT
From: Jim McDonald <jlm@lucid.com>
Message-Id: <8810080001.AA02180@bhopal>
To: Gray@DSG.csc.ti.com
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, KMP@STONY-BROOK.SCRC.Symbolics.COM,
CL-Cleanup@SAIL.Stanford.edu, Bartley@MIPS.csc.ti.com
In-Reply-To: David N Gray's message of Fri, 7 Oct 88 14:02:18 CDT <2801242938-903828@Kelvin>
Subject: Issue: TAIL-RECURSION-OPTIMIZATION (Version 2)
> > That's not true, because a function can't reference -itself-, it can
> > only reference -its name-. For example,
> >
> > (defun foo (x)
> > (if (zerop x) 1 (* x (foo (1- x)))))
> > (setf (symbol-function 'bar) (symbol-function 'foo))
> > (defun foo (x)
> > (* x 2))
> > (bar 3) => 12, not 6
>
> Good point; this example helps clarify the issue: is this the behavior
> desired? I think not, since when the programmer wrote the DEFUN for FOO
> he most likely intended that the call to FOO referred to the function
> he was defining, not to some other FOO that might be defined later.
> Thus, in this case, early binding would cause less surprise than late
> binding.
I agree this is a well-chosen example.
The purist in me says that a user wanting self-recursion should have
written:
(defun foo (x)
(labels ((inner-foo (x)
(if (zerop x) 1 (* x (inner-foo (1- x))))))
(inner-foo x)))
But the pragmatist says that this is cumbersome enough that people
will prefer the simpler version to be self-recursive:
(defun foo (x)
(if (zerop x) 1 (* x (foo (1- x)))))
A solution to this quandry that keeps source code simple would be
to use two different function-defining macros for the two kinds of
behavior.
I.e., DEFUN1 would be a version of DEFUN that produced code using
labels to ensure self-recursion, and DEFUN2 would produce code
that chases through symbols. Then for backwards compatibility,
people can argue whether DEFUN should be equated with DEFUN1 or
DEFUN2, or left for the user or vendor to define.
But if the essence of this argument is accepted, then why not let
(DECLARE (NOTINLINE FOO)) or (DECLARE (INLINE FOO)) discriminate the
two forms? And accepting that premise, it seems that 99.9% of the
time, self-recursion is expected or at worst :-) simply makes the
code run faster. I think this leads to the solution Lucid adopted
(but probably not through this chain of reasoning.)
One advantage I see to declarations over DEFUN1/DEFUN2 is that
DEFUN1 doesn't extend easily to collections of inter-callable
functions, but declarations do (via PROCLAIM).
jlm
∂07-Oct-88 1746 CL-Cleanup-mailer Issue: SYMBOL-MACROFLET (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:46:10 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472922; Fri 7-Oct-88 20:44:46 EDT
Date: Fri, 7 Oct 88 20:44 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SYMBOL-MACROFLET (Version 1)
To: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <880930184754.5.KMP@GRYPHON.SCRC.Symbolics.COM>
Message-ID: <19881008004426.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I mildly favor SYMBOL-MACROFLET:NEW-MACRO. Of course, whatever tweaking
happens to the semantics of SYMBOL-MACROLET, SYMBOL-MACROFLET should
be kept consistent with it.
∂07-Oct-88 1752 CL-Cleanup-mailer Issue SYMBOL-MACROLET-SEMANTICS, Version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:52:35 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472928; Fri 7-Oct-88 20:50:22 EDT
Date: Fri, 7 Oct 88 20:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SYMBOL-MACROLET-SEMANTICS, Version 4
To: Jeffrey Piazza <piazza%lisp.DEC@decwrl.dec.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8809221745.AA27618@decwrl.dec.com>
Message-ID: <19881008005004.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would strongly support SYMBOL-MACROLET-SEMANTICS:SPECIAL-FORM in
version 4, if the following comment had been taken into account.
As it stands I have to oppose it.
SETQ of a symbol macro must be allowed. The reason given [only in older
versions of the proposal] for removing it is wrong -- SETQ of symbol
macros was allowed in order to avoid making any distinction between
symbol macros and variables, which is the only reason symbol macros are
used by CLOS at all.
∂07-Oct-88 1757 CL-Cleanup-mailer Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 17:57:17 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00977g; Fri, 7 Oct 88 17:56:00 PDT
Received: by bhopal id AA02431g; Fri, 7 Oct 88 17:54:19 PDT
Date: Fri, 7 Oct 88 17:54:19 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080054.AA02431@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 13:17 EDT <19881007171716.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: MAKE-PACKAGE-USE-DEFAULT (version 1)
re: ... I don't see how any implementation could be
said not to implement such a proposal!
The issue is not current practice, but CLtL p.183. Indeed, the "Cost"
section points out this obvious situation.
re: Had you intended to propose something specific about the value of
(package-use-list "USER")? Had you intended to propose something
specific about the default for the :use argument to MAKE-PACKAGE? Had
you intended to propose that these must be equal?
No.
On the otherhand, I would expect that most vendors would set their
default in such a way as to make all LISP symbols available, as well
as their vendor-specific ones. But I see no need to spell this out,
since portable code will have to use an explicit :use LISP.
-- JonL --
∂07-Oct-88 1802 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 18:02:12 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472939; Fri 7-Oct-88 21:00:49 EDT
Date: Fri, 7 Oct 88 21:00 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 6)
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: <19881007024901.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <881007210033.6.KMP@BOBOLINK.SCRC.Symbolics.COM>
This looks good to me.
∂07-Oct-88 1805 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 18:04:54 PDT
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00992g; Fri, 7 Oct 88 18:03:38 PDT
Received: by blacksox id AA00551g; Fri, 7 Oct 88 17:59:47 pdt
Date: Fri, 7 Oct 88 17:59:47 pdt
From: Eric Benson <eb@lucid.com>
Message-Id: <8810080059.AA00551@blacksox>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM's message of 2 Oct 88 11:57 PDT <881002-115755-2604@Xerox>
In-Reply-To: Kent M Pitman's message of Sun, 2 Oct 88 15:21 EDT <881002152101.4.KMP@GRYPHON.SCRC.Symbolics.COM>
In-Reply-To: Kent M Pitman's message of Sun, 2 Oct 88 15:54 EDT <881002155456.5.KMP@GRYPHON.SCRC.Symbolics.COM>
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Oct 88 10:56:21 MDT <8810031656.AA13415@defun.utah.edu>
In-Reply-To: David A. Moon's message of Mon, 3 Oct 88 22:51 EDT <19881004025148.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
In-Reply-To: David A. Moon's message of Mon, 3 Oct 88 22:56 EDT <19881004025653.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
In-Reply-To: Sandra J Loosemore's message of Mon, 3 Oct 88 22:00:24 MDT <8810040400.AA13928@defun.utah.edu>
In-Reply-To: David N Gray's message of Wed, 5 Oct 88 18:58:37 CDT <2801087917-5574358@Kelvin>
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 15:16 EDT <19881007191607.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
I am about to prepare a revised version of the proposal. Here are
some specific replies before I start. Sorry about the length, but it
seemed better to reply to all of these together.
Date: 2 Oct 88 11:57 PDT
From: masinter.pa@Xerox.COM
would you say this supercedes:
-----
Issue: SPECIAL-VARIABLE-TEST
Yes, I think it includes everything covered by SPECIAL-VARIABLE-TEST.
Date: Sun, 2 Oct 88 15:21 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Date: 2 Oct 88 11:57 PDT
From: masinter.pa@Xerox.COM
would you say this supercedes:
"supersedes"
Issue: SPECIAL-VARIABLE-TEST
Since EB's proposal is more elaborate and might not get past X3J13, I
would prefer if both were presented and the committee could decide.
I don't want to see the failure of this proposal to pass leave us with
nothing to show.
Seems reasonable to me, although I'm encouraged by the reaction so far
to the new proposal.
Date: Sun, 2 Oct 88 15:54 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
The return values of ENVIRONMENT-VARIABLE-KIND in this proposal clashes
with PROCLAIM-LEXICAL in a bad way. I would prefer if it returned at least
two values:
Value 1 (KIND):
NIL = No declared semantics
LEXICAL = Lexical variable
SPECIAL = Special variable
MACRO = Symbol macro
Value 2 (WHERE-DECLARED):
GLOBAL = Globally declared
LOCAL = Locally declared
NIL = Not declared
This seems like a good idea to me; I'll incorporate it into the
proposal.
A third value you might consider returning is CONSTANT-P, so that a
variable declared by DEFCONSTANT could be distinguished. You could deal
with this by a separate function, though, similar to ENVIRONMENT-INLINE.
Also a good idea. I'm leaning towards Moon's suggestion of combining
all those functions and returning several multiple values from
ENVIRONMENT-VARIABLE-KIND and ENVIRONMENT-FUNCTION-KIND.
Another value to consider is PERVASIVE-P. As currently defined,
PERVASIVE-P is always true when WHERE-DECLARED is GLOBAL and never
true when WHERE-DECLARED is LOCAL. There has been a proposal to
introduce a pervasive special declaration (I'm not sure if it ever
became a formal cleanup issue).
In fact, I also think the returned values (other than T and NIL) should
be keywords because
- keywords are easier to deal with
- keywords are safe here (the set is non-extensible)
- it would be more consistent with other inquiry functions
like FIND-SYMBOL, which return status info in keyword package.
Fine with me. Sandra suggested the same thing. I had considered it
myself before using the defining form names, which I was never
entirely comfortable with.
Your suggested values would map as follows:
KMP suggestion EB suggestion
NIL, NIL NIL
SPECIAL, GLOBAL PROCLAIM
SPECIAL, LOCAL DECLARE
LEXICAL, LOCAL T
MACRO, LOCAL SYMBOL-MACROLET
My proposal leaves a few meaningless combinations, but has the virtue of
being extensible for other situations possibly yet to come, such as:
MACRO, GLOBAL Symbol macros (Symbolics Genera has them)
LEXICAL, GLOBAL Global lexicals (see issue PROCLAIM-LEXICAL)
The following other case which exists now but which you didn't address
might be worth considering, too:
NIL, GLOBAL Reserved words (eg, &FROBOZZ)
Yes, but it doesn't seem very important, since you can find this out
by doing (member x lambda-list-keywords).
I'd also be curious to know why you want ENVIRONMENT-VARIABLE-TYPE to
return NIL in the case where something's undeclared.
I just wanted to be able to distinguish whether the type was declared
T or defaulted to T.
I propose it return
T (the default type, after all), and perhaps offer a second return value
which says whether the information was declared or defaulted. Actually,
come to think of it, the second return value could be NIL, LEXICAL, or
GLOBAL for consistency with my suggestion above.
Yes. I would like to put this all into ENVIRONMENT-VARIABLE-KIND, as
I said.
Perhaps also ENVIRONMENT-INLINE could return as many as three values:
INLINE-P, INLINE-INFO-AVAILABLE-P, and WHERE-DECLARED
so that you could distinguish global from local information, etc.
The reason I suggest these is that a lot of kind of reasoning could
be done by looking only at the first value. The way you have all your
functions structured, you have to case for a lot more things than you
might really want to know. eg, if your only interest is to determine
if a variable is going to do a special reference, you have to look
for two markers (DECLARE and PROCLAIM) under your scheme, but a binary
value under mine. Similarly, if you want to know the type of something,
you have to special-case NIL under your scheme but can just use the
return value directly under mine. Only advanced applications where
more info is needed would need to pick up the additional values. Further,
the additional information is richer than the information provided in
your proposal.
All good ideas.
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Mon, 3 Oct 88 10:56:21 MDT
> Date: Sun, 2 Oct 88 11:30:37 pdt
> From: Eric Benson <eb@lucid.com>
>
> ENVIRONMENT-TARGET env [Function]
>
> This function returns one of the three symbols EVAL, COMPILE or
> COMPILE-FILE, depending on whether the environment is from the
> interpreter, the in-core compiler, or the file compiler. If
> MACROEXPAND or MACROEXPAND-1 is called directly without supplying
> the environment argument, the environment passed to any expander
> functions will have target EVAL.
I really dislike this part of the proposal. I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed. The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file. I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.
Are you comfortable with ENVIRONMENT-REMOTE-P?
As to the claim that CLOS needs this information, my understanding
from reading 88-002R is that what CLOS really needs to store in the
environment is information about the class hierarchy and which
functions are generic functions. (I'm guessing that the current
implementation does not do this, and instead stores the information
externally to the environment in different places depending on whether
it's for the compiler or interpreter.)
On the whole, I'm rather lukewarm about this proposal. I hate to add
this much more complexity to the language but I think it's probably
necessary. When local macro definitions were the only thing that the
environment was used for, you could hack out a code walker by defining
your own representation for environment objects and your own
MACROEXPAND-like function that understands that representation.
No, that doesn't work, because it doesn't allow you to pass the
correct environment to a macro that actually uses the environment.
That's the reason PCL's code walker has implementation-specific hooks
to create and access environments.
I
don't think that's possible any more if we are going to start
requiring that other information (i.e., for CLOS) be stored in the
environment. Also, you really do need access to proclamations (and
not just SPECIAL proclamations).
I intended all of these to provide access to proclamations as well as
declarations. I'll try to make that clearer in the next version.
A minor quibble: on all of the functions in this proposal that return
symbols, how about making them keywords, please?
I agree.
Date: Mon, 3 Oct 88 22:51 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> ENVIRONMENT-TARGET env [Function]
>
> This function returns one of the three symbols EVAL, COMPILE or
> COMPILE-FILE, depending on whether the environment is from the
> interpreter, the in-core compiler, or the file compiler. If
> MACROEXPAND or MACROEXPAND-1 is called directly without supplying
> the environment argument, the environment passed to any expander
> functions will have target EVAL.
I really dislike this part of the proposal. I hate to have to keep
repeating myself, but there are other situations besides the three
listed here in which code may be processed. The example I've cited
before is a filter that reads in code from a file, performs some
preprocessing to decorate the code with lots of type declarations, and
writes it out to another file. I contend that anything that needs to
know whether the code is being processed by the interpreter or
compiler ought to be a special form (this includes EVAL-WHEN and
whatever we decide to do about LOAD-TIME-EVAL) and should be left
strictly alone by code walkers.
I think we have some confusion here between interpreter versus compiler
on the one hand, and operating in the local Lisp world versus outputting
to a file to be loaded later on the other hand. I feel that it is
completely inappropriate to add something that distinguishes between
the compiler and the interpreter. I'd like to see that part of the
proposal dropped.
I agree.
The important distinction is between what I will call local environments
and remote environments. A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
evaluated in a local environment affects the current Lisp world, but in
a remote environment it does not affect the current Lisp world, however
its effects still need to be remembered in a model of the Lisp world
that will be created later. Both COMPILE-FILE and your example program
annotating program work with remote environments. I defy you to come up
with an example where the local/remote environment distinction doesn't
make sense and a third type is needed. Thus I think ENVIRONMENT-TARGET
would better be named ENVIRONMENT-REMOTE-P.
Right.
Date: Mon, 3 Oct 88 22:56 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
I agree with the general tenor of Kent's comments. I'd like to see
an alternate version of the proposal written up that way, so we can
see the ramifications.
I'm working on it.
I also wonder about having separate accessors for scope, type, and
(for functions) inlinitude. Would it be more or less elegant to
have a single accessor that returns all this information as multiple
values? I'd say more elegant, although I'm not sure what happens
if the type was proclaimed but the inlinitude was declared.
I would like to combine all of these aspects into returned values from
ENVIRONMENT-VARIABLE-KIND and ENVIRONMENT-FUNCTION-KIND (and probably
change those names). That's going to mean a lot of retured values,
though. Does anyone think that's a bad idea?
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Mon, 3 Oct 88 22:00:24 MDT
> Date: Mon, 3 Oct 88 22:51 EDT
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> The important distinction is between what I will call local environments
> and remote environments. A defining form (DEFUN, DEFVAR, DEFCLASS, etc.)
> evaluated in a local environment affects the current Lisp world, but in
> a remote environment it does not affect the current Lisp world, however
> its effects still need to be remembered in a model of the Lisp world
> that will be created later. Both COMPILE-FILE and your example program
> annotating program work with remote environments. I defy you to come up
> with an example where the local/remote environment distinction doesn't
> make sense and a third type is needed. Thus I think ENVIRONMENT-TARGET
> would better be named ENVIRONMENT-REMOTE-P.
That's a very nice way to put it. Rather than trying to introduce
*more* kinds of environments, I would actually go in the other
direction and say that code walkers shouldn't even need to know the
distinction between local and remote environments. An implementation
ought to be free to use different representations for the two, but as
long as the accessors return the correct information, is there any
reason why you would need to know where it came from?
> Again the compiler/interpreter distinction is a red herring and CLOS has
> no reason to care about that distinction. The important distinction
> is local/remote. CLOS needs to know whether a DEFCLASS form changes the
> behavior of objects of that class in the current world, or only affects
> a future ("remote") world.
That's pretty much what I was trying to say: CLOS doesn't really need
to know whether the information is needed by the compiler or
interpreter or something else, as long as it finds the right
information.
If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment. The existing proposal assumes that everything the
compiler doesn't create must be an EVAL (that is, local) environment.
Right. AUGMENT-ENVIRONMENT will have to take a :REMOTE-P argument.
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 5 Oct 88 18:58:37 CDT
From: David N Gray <Gray@DSG.csc.ti.com>
> Also, it has
> proven impossible to write a portable code walker in Common Lisp, due
> to insufficient access to the information contained in environments
> and the inability to augment environments with local function
> definitions.
I can see how writing a code walker is easier if you can augment the
local macro information, but I don't see what all the rest of this stuff
is needed for.
"All the rest of this stuff" is useful to code walkers for the same
reason it's useful to compilers.
> Proposal (SYNACTIC-ENVIRONMENT-ACCESS:ADD-FUNCTIONAL-INTERFACE):
>
> The following functions provide information about syntactic
> environment objects. In all of the functions the argument named ENV
> is a environment, of the sort received by the &ENVIRONMENT argument
> to a macro. In all cases it is an error to supply an argument which
> is not a syntactic environment.
I would like to add that it is an error to use an environment object
outside of the dynamic extent of the macro expander invocation which
received it as an &ENVIRONMENT argument. This proposal would be much
easier to implement if the implementation of these accessors were
permitted to, for example, recognize that the environment is a compilation
environment and then fetch the information from wherever the compiler
keeps it, than if the compiler's data structures had to be redesigned to
actually store all of the information in environment objects having
indefinite extent.
The extent of environment objects has been discussed before. I don't
remember whether that became a full-fledged cleanup issue, but I think
it is orthogonal to this issue. Larry, has such an issue been
presented? If not, David, you are welcome to present one.
> ENVIRONMENT-TARGET env [Function]
>
> This function returns one of the three symbols EVAL, COMPILE or
> COMPILE-FILE, depending on whether the environment is from the
> interpreter, the in-core compiler, or the file compiler.
I agree with Moon's comments that the real issue is local versus remote.
> ENVIRONMENT-OPTIMIZE-LEVEL attribute env [Function]
>
> ATTRIBUTE is one of the symbols SPEED, SPACE, SAFETY or
> COMPILATION-SPEED. This function returns an integer between 0 and
> 3, which reflects the current settings of the OPTIMIZE proclamation
> or declaration.
I hope this doesn't require an evaluator to keep track of OPTIMIZE
declarations even though it has no use for them itself.
Or type or inline declarations for that matter. I hate to put in some
weasely wording about how not all of this information may be
available. Does anyone have any feelings about this? I'm inclined to
make interpreters maintain such information in spite of the fact that
they have no use for it. I don't perceive it as a big burden to bear.
For example, I can see how to add it to Lucid's EVAL (which I wrote)
very easily and (I believe) without a noticeable increase in overhead.
How do other people feel about this?
> Rationale:
>
> This proposal provides a portable interface to environment
> information which must otherwise be obtained by
> implementation-dependent means. The ENSURE-GENERIC-FUNCTION and
> FIND-CLASS functions of CLOS require the ENVIRONMENT-TARGET function.
Yes, but I'm not sure that there is anything that can be portably done
with that information. Just because the implementation needs to do
something is not sufficient justification for making it available to
users. In this case, I suspect that CLOS is going to need more than
ENVIRONMENT-TARGET to do everything it needs to do.
What is your suspicion based on?
> A
> useful code walker requires the capability of adding local function
> definitions to an environment.
So who requires the other capabilities?
The other capabilities are not strictly "required" for a code walker
to function, but they are useful.
Date: Fri, 7 Oct 88 15:16 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Mon, 3 Oct 88 22:00:24 MDT
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
....
If the local/remote environment model is adopted (or even if we don't
provide any way to tell the difference between the two), some way
would have to be provided for a code walker to create a remote
environment.
Yes, in EB's proposal AUGMENT-ENVIRONMENT needs a :REMOTE argument
which defaults to the remoteness of the ENV argument and specifies
the remoteness of the returned environment.
Absolutely.
One other thing I would like clarified. It makes sense to be able to
have more than one distinct remote environment around at any given
time; for example, if COMPILE-FILE is called recursively it ought to
create a new remote environment for each file.
That's true, although I was refraining from proposing anything that
complicated. If we get into that, then we also will have to make
environments extensible as I think I mentioned before. But if we
confine ourselves to just putting in a way to tell whether this is a
remote environment or not, that will be enough to get CLOS off the
ground.
Maybe there should be a way to distinguish between remote environments
that do not share a common parent. I can see how that might be
useful. How about if ENVIRONMENT-REMOTE-P returned either NIL or some
non-NIL object that is unique to that particular family of remote
environments? All the calls to COMPILE-FILE within a single
WITH-COMPILATION-UNIT would share the same remote environment parent.
Does it make any sense
to have more than one distinct local environment around, or is there
only one?
There is only one local global environment (gnashing of teeth in the
background over the terminology) in Common Lisp, but there can be more
than one in some dialects of Scheme (they're called "locales").
Multiple local global environments seem like a sound approach to solving
the same problems that packages were invented to solve.
On the terminology, this shows that "remote" is an okay word, but we
shouldn't use "local" as the antonym of "remote", since "local" is already
used as the antonym of "global". How about "running"?
How about "resident"?
∂07-Oct-88 1812 CL-Cleanup-mailer Issue: SETF-SUB-METHODS (Version 5)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 18:11:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472948; Fri 7-Oct-88 21:10:26 EDT
Date: Fri, 7 Oct 88 21:10 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: SETF-SUB-METHODS (Version 5)
To: cl-cleanup@sail.stanford.edu
In-Reply-To: <881006-153004-1550@Xerox>
References: <19880607212838.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19881008011002.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
My comments on version 4, in the second referenced message, still apply.
I guess I ought to repeat them: [I guess the dont-cares have been
removed, at least, I couldn't find them]
Date: Tue, 7 Jun 88 17:28 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The writeup is much improved. I favor SETF-SUB-METHODS:DELAYED-ACCESS-STORES.
I don't think it's accurate to say there is no cost to users. For
example, the original setf of getf example, which was proposed by a
user, will behave differently under this proposal than it behaved in
several implementations. Users of those implementations might have been
depending on the old behavior. You can say there is no effect on
portable programs, but you can't say that no users will be affected.
Even users who had ported programs among several implementations
and mistakenly concluded that their programs were portable might
be affected.
I think the <dont care>s in the test cases should be removed. CLtL
specifies specific values to be returned by all these forms; while
those values are irrelevant to the current issue, I think it is
better practice to include them in the test cases. Otherwise
someone might think you were proposing to stop specifying specific
values to be returned, and allow the values to become
implementation-dependent.
I was asked to provide Current Practice information for Symbolics:
Symbolics Genera 7.2 foolishly adopted an earlier proposal
(SETF-METHOD-FOR-SYMBOLS) before it was officially approved by X3J13 and
its parent standards organization. This proposal is incompatible with
that one, so Genera 7.2 does not implement the behavior described here,
and fails test cases 1, 2, 4, 5, and 6. I believe Symbolics Genera 7.1
is closer to this proposal, however I don't have access to it so I didn't
test it.
I didn't test Symbolics CLOE, perhaps Kent can provide information on it.
An earlier version of the proposal had Current Practice information
for Xerox, Franz, HP, and DEC. Where did it go?
∂07-Oct-88 2013 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:13:38 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01161g; Fri, 7 Oct 88 20:12:26 PDT
Received: by bhopal id AA02929g; Fri, 7 Oct 88 20:10:43 PDT
Date: Fri, 7 Oct 88 20:10:43 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080310.AA02929@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 22:00 EDT <19881008020002.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
re: What's a "component"?
It's "half a loaf" of a "first cut".
Yea, I know that a :print-function can grab information which is not at
all apparent from the defined components of an object. But it's "rare".
The "first cut" simply doesn't stop where the _default_ structure printer
would stop.
-- JonL --
∂07-Oct-88 2018 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (version 1.1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:18:38 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472980; Fri 7-Oct-88 21:46:41 EDT
Date: Fri, 7 Oct 88 21:46 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (version 1.1)
To: Christopher.McConnell@A.GP.CS.CMU.EDU
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: The message of 7 Oct 88 15:50 EDT from Christopher.McConnell@A.GP.CS.CMU.EDU
Message-ID: <19881008014611.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
PRINT-CIRCLE-STRUCTURE: looks good to me.
∂07-Oct-88 2019 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:18:53 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472984; Fri 7-Oct-88 21:50:18 EDT
Date: Fri, 7 Oct 88 21:50 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 2)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810072337.AA02095@bhopal>
Message-ID: <19881008015000.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 7 Oct 88 16:37:53 PDT
From: Jon L White <jonl@lucid.com>
I'll make another version of this proposal before Larry's ultimate deadline;
but first I'd like to see if there are any other reactions to these
comments.
re: There is no guarantee that any state implicit in the invocation of the
form (<next-fn>) will survive outside the scope of the WITH-... form.
The word "scope" here is a typo for "extent". In addition, it's hard to
figure out what this means, since it does not use the standard
terminology for describing exceptions. Why not say, "It is an error to
evaluate the form (<next-fn>) outside the dynamic extent of the body of
the WITH-... form"?
Both "scope" and "extent" are involved here -- the form (<next-fn>) is
defined only within the scope, and any objects which it may create have
validity only within the "extent" of the WITH-... The reason I don't
want to use "It is an error ..." to describe the "extent" constraint
is that the buzz phrase "It is unspecified" (from the "new" error
terminology) is more appropriate here. Implementations which don't use
the Symbolics style "locking" might actually provide indefinite extent
so that the Generators proposal will not be limited.
I haven't gotten myself up to date on the new exception terminology yet,
not being on the editorial committee. I think you don't think "is an error"
means the same thing that I think it means, but "unspecified" is okay with me.
I hope the new exception terminology doesn't use words with legal force
such as "guarantee."
re: The syntax of WITH-PACKAGE-ITERATOR is rather baroque. It has an optional
subform (<package>) preceding a required subform (<type>),
Yea, I didn't like that either. An &optional is fine with me; Mlynarik
even suggested &key parameters.
That might be a good idea, then :INTERNAL and :EXTERNAL and :INHERITED
can be specified independently. I haven't thought about it for more
than five seconds.
∂07-Oct-88 2019 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:19:11 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472990; Fri 7-Oct-88 22:00:21 EDT
Date: Fri, 7 Oct 88 22:00 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
To: Jon L White <jonl@lucid.com>
cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: <8810080135.AA02628@bhopal>
Message-ID: <19881008020002.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 7 Oct 88 18:35:06 PDT
From: Jon L White <jonl@lucid.com>
re: Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
Circularities need only be detected for
objects that would normally be printed by the default structure
print-function.
I cannot accept any proposal with this kludgey restriction in it. If
circularities are going to be detected at all, they should be done
right. It's not difficult to call the user-defined print-function once
with a special stream argument that detects what the function prints
(i.e. what calls to WRITE and equivalent functions and FORMAT directives
it makes using that stream), and use that for circularity detection.
That's how the Symbolics Genera implementation works.
A "first cut" implementation is merely to descend all components of objects
when looking for circularities. At worst this will cause spurious #n='s
to appear in the output (which CLtL doesn't seem to proscribe), and may
impose some extra traffic on the "looker" (probably a hash-table).
What's a "component"?
Suppose I'm using defstruct instead of CLOS, and I want to add a slot
compatibly. Since I'm not using CLOS, I have to store that slot in a
table on-the-side. How does the component finder find it? The answer is
that it can't, which is why I maintain that the only viable approach is
to based circularity detection on what the user-defined print function
actually prints, not on any guesses as to what it might print.
∂07-Oct-88 2028 CL-Cleanup-mailer Re: several hundred ugly things
Received: from SEF1.SLISP.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:28:00 PDT
Received: from SEF1.SLISP.CS.CMU.EDU by SEF1.SLISP.CS.CMU.EDU; 7 Oct 88 23:25:31 EDT
To: Jim McDonald <jlm@lucid.com>
cc: masinter.pa@Xerox.COM, CL-Cleanup@SAIL.STANFORD.EDU
Subject: Re: several hundred ugly things
In-reply-to: Your message of Fri, 07 Oct 88 12:09:20 -0700.
<8810071909.AA01126@bhopal>
Date: Fri, 07 Oct 88 23:24:07 EDT
From: Scott.Fahlman@B.GP.CS.CMU.EDU
... You develop your program using whatever parts of the full
language you need, then compile in a way that trims away anything that
wasn't used. This creates a subset of Common Lisp that exactly fits the
needs of the application in question. A simple version of this is trivial
to implement in any system that has a copying GC; ...
If only that were true. For example, a routine that uses + implicitly
uses bignums and complex numbers, plus ERROR to handle problems like
(+ 'a '(foo)). Bignums require GC. ERROR uses FORMAT, READ, and
EVAL. FORMAT uses..., and pretty soon you've got the kitchen sink
again.
Well, in addition to just depending on the GC, you probably also want to
give the user some way of declaring that his application doesn't use
certain features such as bignums, complexes, floating point, the error
system (just terminate instead), circular printing, or whatever. The point
I'm trying to make is that you shouldn't try to impose a single subset on
everyone, but should allow each user to select the subset he needs.
-- Scott
∂07-Oct-88 2041 CL-Cleanup-mailer Issue: PACKAGE-DELETION (Version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:41:09 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01120g; Fri, 7 Oct 88 19:20:57 PDT
Received: by bhopal id AA02759g; Fri, 7 Oct 88 19:19:18 PDT
Date: Fri, 7 Oct 88 19:19:18 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080219.AA02759@bhopal>
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
Cc: CL-Cleanup@SAIL.Stanford.EDU
In-Reply-To: Kent M Pitman's message of Fri, 7 Oct 88 20:36 EDT <881007203609.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
Subject: Issue: PACKAGE-DELETION (Version 4)
re: Grumble.
For the record, I don't really think that
(DELETE-PACKAGE no-such-name)
should be treated the same as
(DELETE-PACKAGE unregistered-package)
Kent, I didn't change any of that. I know, my msg said "added the minor
corrections"; but I didn't take altering the semantics of DELETE-PACKAGE
to be a "minor" correction, so I didn't do it. Could you double check to
be sure that you didn't misread something?
re: I also deliberately did not say that delete package returns T if the
deletion is successful "and otherwise returns NIL" since sometimes it
does not return at all.
Is this really worth belaboring? You do have to say what it returns
in the case when you call it on an already deleted package.
-- JonL --
∂07-Oct-88 2018 CL-Cleanup-mailer New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:18:38 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472958; Fri 7-Oct-88 21:18:48 EDT
Date: Fri, 7 Oct 88 21:18 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
To: eb@lucid.com
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <8810080059.AA00551@blacksox>
Message-ID: <881007211835.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Fri, 7 Oct 88 17:59:47 pdt
From: Eric Benson <eb@lucid.com>
I am about to prepare a revised version of the proposal. Here are
some specific replies before I start. Sorry about the length, but it
seemed better to reply to all of these together.
...
A couple other comments which will hopefully be of use to you in your
new proposal; I asked the others in the Cloe group what they thought of
your proposal -- mostly from a technical impact point of view -- and
this is the kind of thing I got back...
In Cloe Runtime (meaning, our compiler for the 386), the information
you mention is all accessible, but very little of it is stored in the
environment object. Only information about macrolet, symbol-macrolet,
and symbol-macroflet is in the environment object itself. Other information
is obtained dynamically.
The belief is that it would be a fair amount of work for us to put the
information in the environment object and the gain was not made obvious
by the proposal. Can you give an example of a screw case that would come
from saying the information is dynamically available in the macro only
(ie, you couldn't embed funargs that were closed over the current state
in s-expression and then ask that it be macroexpanded and have the
macroexpander funcall the funarg it found embedded in the structure in
some other environment context ... I can't imagine this ever happening,
and it's one of the only screw cases I could devise).
Basically, they seemed to feel that both of the functionalities you were
considering offering and the manner of presentation (ie, environment
extraction) were somewhat unmotivated. This is not to say that they
thought you had not motivation -- only that you didn't present it in a
way that made them able to figure out how you chose the set of things
you did, what benefits would come, etc. Hopefully the next write-up will
address this issue in greater detail.
∂07-Oct-88 2019 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 2)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:18:57 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 472985; Fri 7-Oct-88 21:53:29 EDT
Date: Fri, 7 Oct 88 21:53 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 2)
To: masinter.pa@Xerox.COM
cc: cl-cleanup@sail.stanford.edu
In-Reply-To: <881007-162444-1360@Xerox>
Message-ID: <19881008015308.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I can't read this, it's full of typos, at least near the beginning.
Either that or my eyes are going from dealing with 300 or 400
messages of mail backlog in the last two days.
∂07-Oct-88 2041 CL-Cleanup-mailer Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:41:17 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01063g; Fri, 7 Oct 88 18:36:46 PDT
Received: by bhopal id AA02628g; Fri, 7 Oct 88 18:35:06 PDT
Date: Fri, 7 Oct 88 18:35:06 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080135.AA02628@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, Christopher.McConnell@A.GP.CS.CMU.EDU
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 00:22 EDT <19881007042246.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: PRINT-CIRCLE-STRUCTURE (Version 1)
re: Date: 5 Oct 88 20:47 PDT
From: masinter.pa@Xerox.COM
Circularities need only be detected for
objects that would normally be printed by the default structure
print-function.
I cannot accept any proposal with this kludgey restriction in it. If
circularities are going to be detected at all, they should be done
right. It's not difficult to call the user-defined print-function once
with a special stream argument that detects what the function prints
(i.e. what calls to WRITE and equivalent functions and FORMAT directives
it makes using that stream), and use that for circularity detection.
That's how the Symbolics Genera implementation works.
A "first cut" implementation is merely to descend all components of objects
when looking for circularities. At worst this will cause spurious #n='s
to appear in the output (which CLtL doesn't seem to proscribe), and may
impose some extra traffic on the "looker" (probably a hash-table).
-- JonL --
∂07-Oct-88 2041 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 20:41:26 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01042g; Fri, 7 Oct 88 18:28:13 PDT
Received: by bhopal id AA02590g; Fri, 7 Oct 88 18:26:34 PDT
Date: Fri, 7 Oct 88 18:26:34 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080126.AA02590@bhopal>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-cleanup@sail.stanford.edu, masinter.pa@xerox.com, pedersen.pa@xerox.com
In-Reply-To: David A. Moon's message of Fri, 7 Oct 88 16:02 EDT <19881007200231.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 5)
re: [JonL] Here's the thing that keeps me from being as upset at this situation
as you are -- there are *several* places where "objects" can be stored
that one may desire specialization a la array-element-type. In particular
Lucid's customers keep asking for this sort of thing in defstructs and
flavor instances, and I notice with some chagrin the cleanup proposal
on type-specialized lists (e.g. list-of-unsigned-byte-8 or whatever).
Right now Common Lisp only uses "declaration versus discrimination" in
connection with ARRAY and COMPLEX.
Had we thought of it before, this issue should have been called
TYPE-SPECIFIER-SPECIALIZATION:UNIFY-DECLARATION. Your addition
of the COMPLEX stuff is ok by me, since it doesn't detract from the
fixup of arrays, nor from similar directions in the future.
But, in the future, we may have to worry about any lurking remnants of
the "schizophrenia"; I think it is more pervasive, in implicit ways,
than the explicit losage in the section 4.5.
re: I didn't see this message before sending my proposed revision
of ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS, because the message
was not sent to the mailing list, only to individuals.
. . .
Date: Wed, 5 Oct 88 15:43:44 PDT
From: Jon L White <jonl@lucid.com>
. . .
IMPLEMENTED-ARRAY-ELEMENT-TYPE
I'd really prefer that to
IMPLEMENTATION-ARRAY-ELEMENT-TYPE
[Moon] Either of these names would be okay with me. I would have
included the one you proposed in my revision of the proposal if I had
seen this message in time.
If you don't mind, then, I'll change it to IMPLEMENTED-ARRAY-ELEMENT-TYPE,
and analogously will change IMPLEMENTATION-COMPLEX-COMPONENT-TYPE to
IMPLEMENTED-COMPLEX-PART-TYPE [See CLtL, p220 and p47 where the "elements"
of a complex number are called "parts"]
-- JonL --
∂07-Oct-88 2128 CL-Cleanup-mailer Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:28:26 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01220g; Fri, 7 Oct 88 21:27:13 PDT
Received: by bhopal id AA03150g; Fri, 7 Oct 88 21:25:34 PDT
Date: Fri, 7 Oct 88 21:25:34 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080425.AA03150@bhopal>
To: cl-cleanup@sail.stanford.edu
In-Reply-To: Jon L White's message of Fri, 7 Oct 88 00:14:21 PDT <8810070714.AA07902@bhopal>
Subject: Issue: HASH-TABLE-PACKAGE-GENERATORS (version 3)
I've altered the syntax of with-package-iterator after seeing a suggestion
from Richard Mlynarik; also I've clarified a few wordings as per moon's
recent mail. And finally, I've added another example.
-- JonL --
!
Issue: HASH-TABLE-PACKAGE-GENERATORS
References:
Category: ADDITION
Edit history: Version 1, 23-May-88 JonL
Version 2, 6-Oct-88 JonL (convert to "with" scoping).
Version 3, 7-Oct-88 JonL (mly's syntax for package iterator)
Problem description:
The Iteration subcommittee would like the several iteration proposals to be
writeable in portable Common Lisp code. Unfortunately, the only complete
access to hash-tables and packages is through MAPHASH and DO-SYMBOLS (and
DO-EXTERNAL-SYMBOLS and DO-ALL-SYMBOLS); none of these existing primitives
is satisfactory for building complex iteration clauses.
Proposal (HASH-TABLE-PACKAGE-GENERATORS:ADD-WITH-WRAPPER)
Add two new macros WITH-HASH-TABLE-ITERATOR and WITH-PACKAGE-ITERATOR
to the language as follows:
WITH-HASH-TABLE-ITERATOR ((<next-fn> <hash-table>) &body body) [Macro]
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the hash-table which is obtained
by evaluating <hash-table> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. the key item (of a <key, value> pair)
;; 3. the value item (of a <key, value> pair)
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
WITH-PACKAGE-ITERATOR ((<next-fn> <package> [Macro]
&key external internal inherited)
&body body)
Within the lexical scope of 'body', the name <next-fn> is defined
via MACROLET such that successive invocations of (<next-fn>) will
return the items, one by one, from the package which is obtained
by evaluating <package> [only once].
An invocation (<next-fn>) returns three values as follows:
;; 1. a boolean indicating whether an entry is returned (T says yes)
;; 2. a symbol (available in the indicated package)
;; 3. the availability type for that symbol; i.e. one of
;; :INTERNAL, :EXTERNAL, or :INHERITED, or unspecified for
;; the DO-ALL-SYMBOLS case.
;; After all entries have been returned [by successive invocations of
;; (<next-fn>)], then only one value is returned, namely NIL.
The keyword arguments are flags indicating which kinds of symbols are
wanted; they are not "evaluated". The following combinations are
recognized:
+----------+----------+-------------+--------------------------------------
| external | internal | inherited | CLtL macro equivalent
+----------+----------+-------------+-------------------------------------
| T | T | T | DO-SYMBOLS
| T | T | NIL | DO-PRESENT-SYMBOLS [not CLtL]
| T | NIL | T | <none> [unspecified]
| T | NIL | NIL | DO-EXTERNAL-SYMBOLS
| NIL | T | T | <none> [unspecified]
| NIL | T | NIL | DO-INTERNAL-SYMBOLS [not CLtL]
| NIL | NIL | T | DO-INHERITED-SYMBOLS [not CLtL]
| NIL | NIL | NIL | DO-ALL-SYMBOLS
+----------+----------+-------------+--------------------------------------
In the default case, equivalent to DO-ALL-SYMBOLS, the value of the
<package> argument is ignored. The lines marked "[not CLtL]" mention
package iterator macros found in some implementations of Common Lisp;
their meaning should be self-explanatory. The lines marked "unspecified"
may be extended by an implementation to have the implied meaning.
In accord with common practice, the options that include "inherited"
symbols, and the DO-ALL-SYMBOLS option, are allowed to present the
same symbol multiple times. This is because a symbol may be "inherited"
from several different used packages; and a symbol may be present in
several different packages (in the DO-ALL-SYMBOLS case).
It is unspecified what happens if any of the implicit interior state
of an iteration is returned outside the dynamic extent of the WITH-...
form (such as by returning some closure over the invocation form).
Test-case:
The following function should return T on any hash-table, and signal
an error if the usage of 'with-hash-table-iterator' doesn't agree
with the corresponding usage of 'maphash'.
(defun test-hash-table-iterator (hash-table)
(let ((all-entries '())
(generated-entries '())
(unique (list nil)))
(maphash #'(lambda (key value) (push (list key value) all-entries))
hash-table)
(with-hash-table-iterator (generator-fn hash-table)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? key value) (generator-fn)
(unless more? (return))
(unless (eql value (gethash key hash-table unique))
(error "Key ~S not found for value ~S" key value))
(push (list key value) generated-entries))))
(unless (= (length all-entries)
(length generated-entries)
(length (union all-entries generated-entries :test #'equal)))
(error "Generated entries and Maphash entries don't correspond"))
t))
The following function should return T on any package, and signal
an error if the usage of 'with-package-iterator' doesn't agree
with the corresponding usage of 'do-symbols'.
(defun test-package-iterator (package)
(unless (packagep package)
(setq package (find-package package)))
(let ((all-entries '())
(generated-entries '()))
(do-symbols (x package)
(multiple-value-bind (symbol accessibility)
(find-symbol (symbol-name x) package)
(push (list symbol accessibility) all-entries)))
(with-package-iterator (generator-fn package
:internal t :external t :inherited t)
(loop
;;Note -- this is the "trivial" LOOP of CLtL p121
(multiple-value-bind (more? symbol accessibility) (generator-fn)
(unless more? (return))
(let ((l (multiple-value-list (find-symbol (symbol-name symbol)
package))))
(unless (equal l (list symbol accessibility))
(error "Symbol ~S not found as ~S in package ~A [~S]"
symbol accessibility (package-name package) l))
(push l generated-entries)))))
(unless (and (subsetp all-entries generated-entries :test #'equal)
(subsetp generated-entries all-entries :test #'equal))
(error "Generated entries and Do-Symbols entries don't correspond"))
t))
The following functions prints out every interned symbol:
(defun print-all-symbols ()
(with-package-iterator (next-symbol nil)
(print (next-symbol))))
Rationale:
The particular way in which hash-tables and packages are represented
need not be standardized, or even exposed to the user. Yet a simpler
handle on them is needed for the various iteration paradigms to be written
in portable code. In fact, after these iterator macros are put into an
implementation, then MAPHASH and DO-<mumble>-SYMBOLS are trivial usages
of them; but no _efficient_ use of the current primitives will provide
the effect of the new macros, namely a form that _returns_ the elements
of a table "one by one".
Current Practice:
Nobody does it this way, but both Symbolics and Lucid are not far off.
Cost to Implementors:
Moderate. Possibly a couple day's to a week's work for an implementation
that has to start completely afresh. Something like this is already being
done by the standard package macros [CLtL, p187].
Cost to Users:
None.
Benefits:
Will provide a more basic primitive for iterating over hash-tables and
packages; will permit new iteration paradigms to be written in portable code.
Aesthetics:
All other things being equal, it is better to have more general primitives
than less general ones.
Discussion:
The Iteration Subcommittee supports this proposal (or, "used to" --
JonL 6-Oct-88).
One must be careful not to assume that the invocation (<next-fn>) is a
"generator" function call -- since <next-fn> is MACROLET'd in an
implementation dependent way, it could even turn into a special form like
(if something
(values nil)
(yet-another-function-call))
The scoping called for herein may not be quite so useful to the "generators"
style proposals; in particular they offer an interface wherein one may
create a "generator" function of indefinite extent that returns, one-by-one,
the elements of the table. The constrained scoping implicit in these
WITH-... macros is not so much for any kind of optimization, but rather
for coordination of such hash-table "locking" as may occur in multi-
processing implementations like Symbolics. Nevertheless, Dick Waters
thinks these macros should be put in anyway, since it clearly is a
requirement for a portable LOOP, and can be use in a limited context
(i.e., not "indefinite scope") for portable versions of ITERATE and OSS.
Of course, if an implementation _can_ support an indefinite extent for
a "generator" object returned out of the iterator forms, it is allowed
to do so by this proposal.
∂07-Oct-88 2149 CL-Cleanup-mailer Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:49:48 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 16:46:42 PDT
Date: 7 Oct 88 16:28 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: LIST-TYPE-SPECIFIER (Version 1)
In-reply-to: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Thu, 6 Oct 88 03:16 EDT
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: Beckerle@XX.LCS.MIT.EDU, Masinter.PA@Xerox.COM, eb@Lucid.COM,
CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881007-164642-1409@Xerox>
I don't this can be released with such divergent views on what it does.
It would help to talk about the generic capabilities of the type specifiers
independently of their names. I'm not sure that either of the kinds of type
specifiers people want to add make sense, whether you have to have a new
kind of CONS cell or whether it really talks about the old kind.
For discussion on Monday.
∂07-Oct-88 2150 CL-Cleanup-mailer Issue: LISP-SYMBOL-REDEFINITION (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:18 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 19:03:59 PDT
Date: 7 Oct 88 19:04 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: LISP-SYMBOL-REDEFINITION (Version 3)
to: cl-cleanup@sail.stanford.edu
Line-fold: NO
Message-ID: <881007-190359-1626@Xerox>
David was right; version 2 was full of typos. The original problem description -- about an incident where a beginning user redefined MAKE-LIST -- is not in fact really addressed by this issue, since we haven't required implementations to signal an error (and don't want to.)
!
Issue: LISP-SYMBOL-REDEFINITION
References: Cleanup issue PACKAGE-CLUTTER
CLtL pp 67-69 Defining named functions
Category: CLARIFICATION
Edit history: Masinter, Version 1, 17-Sep-88 from (Kolb, 14-Aug-87)
Masinter, Version 2, 7-Oct-88
Masinter, Version 3, 7-Oct-88, fix typos
Problem description:
Is it legal to redefine Common Lisp functions? There is no explicit
prohibition, and many implementations do allow redefinition of
functions in the Lisp package.
CLtL only says that special forms can not be redefined. But this doesn't
solve the general problem of redefining system functions.
Proposal LISP-SYMBOL-REDEFINITION:DISALLOW
The results of redefining as a function any of the functions,
macros, or special forms defined in the LISP package are unspecified;
similarly, the result of lexically defining (with FLET, LABELS or
MACROLET) any function or macro in the LISP package is unspecified.
Clarify that, as implied by CLtL p. 69, it is an error to rebind
any symbol in CL defined as a constant.
The results of applying TRACE to any function in the LISP package is
unspecified.
Following the proposed definition of "results are unspecified", this means that
implementations may signal an error, or other unspecified behavior may
ensue. For example, programming environments may warn the user about
redefinition of LISP symbols and then allow them. Some environments may
distinguish between functions that are safe to redefine and those that are
not.
Examples:
The behavior of the construct:
(FLET ((OPEN (filename &key direction) (format t "Open called....")
(OPEN filename :direction direction)))
(with-open-file (x "frob" :direction ':output)
(format t "was Open called?")))
is unspecified; for example, the macro expansion of with-open-file might refer
to the OPEN function and might not.
(defun car (x) (cdr x))
might signal an error.
Rationale:
This proposal is the only simple resolution of the problem description that
we can imagine that is consistent with current implementation techniques.
Allowing arbitrary redefinition of symbols in the LISP package would place
severe restrictions on implementations not to actually use those symbols in
macro expansions of other LISP symbols, in function calls, etc. While some
looser restrictions might do for any particular Common Lisp implementation,
there seems to be no good way to distinguish between those symbols that are
redefinable and those that are not.
In general, programs can redefine functions safely by creating new symbols in
their own package, possibly shadowing the name.
Current practice:
Many Lisp environments have some mechanism for warning about redefinition of
Lisp symbols and preventing accidental redefinition while allowing it where
necessary (e.g., to patch the Lisp system itself, fix a bug, add an
optimization.)
Fewer check for lexical redefinition, since such redefinition is not as
dangerous. Certainly, there are some symbols that are never used in macro
expansions of the standard Common Lisp macros. However, implementations do
differ on the behavior of macro expansions.
Cost to Implementors:
This proposal clarifies the status quo -- that the results are unspecified. It
allows and encourages implementors to check for such redefinition, but does not
require it.
Cost to Users:
This proposal clarifies that implementations are free to check for a condition
that they might not have before, and may clarify that some current user code is
non-portable.
Benefits:
This issue frequently arises. Adopting this proposal would clarify a frequent
source of question about Common Lisp.
Cost of non-adoption:
Continued questions.
Esthetics:
Disallowing all redefinition is the simplest way of disallowing the ones that
really are trouble.
Discussion:
There have been various proposals for allowing users to extend the "protection"
mechanism to their own macros, functions, packages. These proposals seem like
they are environment issues and not language ones, however.
It is unfortunate that the restriction on reusing LISP package symbols in
FLET, LABELS or MACROLET is necessary, but the research into straightening out
the syntactic environment of macroexpansion isn't mature enough to put into
a standard yet.
∂07-Oct-88 2150 CL-Cleanup-mailer Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:49:53 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 18:33:31 PDT
Date: 7 Oct 88 18:33 PDT
From: masinter.pa@Xerox.COM
Subject: Re: New Issue: SYNTACTIC-ENVIRONMENT-ACCESS
In-reply-to: Eric Benson <eb@lucid.com>'s message of Fri, 7 Oct 88 17:59:47
pdt
To: Eric Benson <eb@lucid.com>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881007-183331-1589@Xerox>
re: "The extent of environment objects has been discussed before. I don't
remember whether that became a full-fledged cleanup issue, but I think
it is orthogonal to this issue. Larry, has such an issue been
presented? If not, David, you are welcome to present one."
Until I get my Common Lisp Mail Super-Duper Retrieval System up and running
again, I can't answer this question. I don't remember one...
I don't think that requiring interpreters to remember type declarations
will go over big.
I actually don't think adding a lot of functions & variables will go over
big unless there's a stronger justification for them than the ones
presented here.... I know and you know why this stuff is useful, but do
*they* know?
∂07-Oct-88 2150 CL-Cleanup-mailer Re: Issue: SETF-SUB-METHODS (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:49:58 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 18:38:44 PDT
Date: 7 Oct 88 18:38 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: SETF-SUB-METHODS (Version 5)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Fri, 7 Oct 88 21:10 EDT
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: cl-cleanup@sail.stanford.edu
Message-ID: <881007-183844-1594@Xerox>
David: I thought I responded to almost all of your comments;
In response to your complaint about "no cost to users", I rewrote Cost to
Users.
I removed the <dont care>s from the test cases.
I incorporated your remarks about Symbolics Genera 7.2 in Current Practice.
I thought JonL had responded to the reason why he removed the Current
Practice for Xerox, Franz, HP and DEC, and agreed that the test cases had
changed and so regenerating them would require some extra work and not be
necessary.
∂07-Oct-88 2150 CL-Cleanup-mailer Issue: PACKAGE-CLUTTER (Version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 21:50:05 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 18:54:38 PDT
Date: 7 Oct 88 18:54 PDT
From: masinter.pa@Xerox.COM
Subject: Issue: PACKAGE-CLUTTER (Version 4)
To: CL-Cleanup@SAIL.Stanford.EDU
Message-ID: <881007-185438-1615@Xerox>
As for removing SYSTEM; it is no worse than the other packages that might
be in an implementation. Its not just package names, its also package
nicknames, right?
I don't see any reason not to also allow USER to have symbols, if it can
:USE other packages. For example, what if your system first reads an init
file and the init file is in-package "USER", then the first thing that the
"real" user will see might have a few symbols from the init file actually
interned in "USER". As long as it doesn't have to be empty, there's no
reason to make it only :USE other packages, is there?
I've modified the proposal in response to Kent's other comments.
!
Issue: PACKAGE-CLUTTER
References: LISP, USER, SYSTEM packages (p181)
Related issues: LISP-SYMBOL-REDEFINITION, DEFPACKAGE,
MAKE-PACKAGE-USE-DEFAULT, IN-PACKAGE-FUNCTIONALITY
Category: CHANGE/CLARIFICATION
Edit history: 07-Jul-88, Version 1 by Pitman
23-Sep-88, Version 2 by Masinter
5-Oct-88, Version 3 by Masinter
Problem Description:
CLtL specifies that
``The package named LISP contains the primitives of
the Common Lisp system. Its external symbols include
all of the user-visible functions and global variables
that are present in the Common Lisp system, such as
CAR, CDR, *PACKAGE*, etc. Almost all other packages will
want to use LISP so that these symbosl will be accessible
without qualification.''
It specifies "all" but not "all and only".
Some implementations place their extensions in the Lisp package.
Nothing in CLtL explicitly prohibits this, but it leads to problems
in general. For example:
- A user defining a function by a name not mentioned in CLtL may be
surprised to clobber a system function in some implementations
- In one particular implementation, the variable HELP was a system
constant, so that ((LAMBDA (HELP) ...HELP...) "Press ? for help.")
signalled a correctable error (asking what variable to bind
instead of HELP :-).
Proposal (PACKAGE-CLUTTER:REDUCE):
Specify that, not only must the LISP package contain at least all of the
symbols listed in the standard, it will have no other external symbols.
(The LISP package may have additional internal symbols.)
Symbols on the LISP package may have function or macro
definitions, top level value or SPECIAL proclamations, or
type definitions only if explicitly permitted in the specification.
That is, a program is valid Common Lisp if it assumes that
this is true; for example, FBOUNDP will be false for all
external symbols of the LISP package except those documented
to be functions or macros; BOUNDP will be false for all
those except those documented to be variables,
and portable programs can use symbols in the LISP package
as local lexical variables with the presumption that the variables
are not proclaimed special, except for those variables specified
as constants or variables.
(The proposal LISP-SYMBOL-REDEFINITION addresses the
converse; that is, what user programs are allowed to do.)
Eliminate the requirement that the initial Common Lisp system
have a package named "SYSTEM". Specify that implementations may
have several other packages available, that these should be
documented. If it is appropriate, the standard might contain
as an example that implementations might have a package named
"SYSTEM".
Clarify that the "USER" package may have additional symbols interned
within it and that it may :USE other implementation-specific packages.
Examples:
#1: The symbol HELP may not be on the LISP package because it is not
mentioned in CLtL.
#2: The symbol VARIABLE is specified to be on the LISP package (because
it is a valid second argument to the DOCUMENTATION function). Since
it is not defined as a variable, type, or function, however, it will
not initially be bound, defined as a type, or defined as a function,
macro or special form.
Rationale:
If extra symbols are permitted in the LISP package, users may be
surprised
by relationships between the LISP package and other packages which they
did not expect, or may be surprised by functionality that they did not
expect. The degenerate case is:
(DEFCONSTANT LISP:A 'YOU-LOSE)
(DEFCONSTANT LISP:B 'YOU-LOSE)
(DEFCONSTANT LISP:C 'YOU-LOSE)
...
(DEFCONSTANT LISP:AA 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
(DEFCONSTANT LISP:AB 'YOU-LOSE)
...etc.
Given such an implementation, even things like (LAMBDA (X) X) are not
valid because they attempt to bind "system constants". It is necessary
that the programmer be able to know for sure that an arbitrary name is
"free for use" and best way to conveniently assure this is to require
that the LISP package be unadulterated.
As for the additional definitions, there are situations where additional
definitions would cause a problem. For example, if a symbol on the Lisp
package were declared as a special variable even though that value was
not mentioned in the standard, that variable would behave incorrectly
when
used as a lexical variable. Similarly, if a symbol in the lisp package
were defined as an implementation-dependent special form, problems might
result if a user redefined or even bound (as by FLET or MACROLET) that
name.
The LISP package is the foothold from which portable programs establish
their desired environment. Careful control is desirable to make sure
everyone is starting off on the right foot.
Current Practice:
Some implementations have been known to add additional symbols (usually
functional and/or variable extensions) to the LISP package.
Several implementations have restricted the LISP package to only contain
those symbols in CLtL. (The exact set was difficult to extract because
not all
LISP package symbols appeared in the index of CLtL.)
Even in those implementations that have only the prescribed symbols in
CLtL,
there can be extra definitions for those symbols. For example, in
Symbolics Genera,
the symbols EVALHOOK, ROOM, and APPLYHOOK
are spuriously defined as special variables, and the symbol LAMBDA is
defined
as a macro.
Performance Impact:
None
Cost to Implementors:
The actual cost of moving the symbols out of the LISP package in cases
where they are not already gone is quite small. However, if any
implementation really has to do this, it may have a number of
suppositions
about what is in what package, and the changes could potentially be
extensive.
Cost to Users:
This change is upward compatible with any portable program, but users
of a particular implementation's extensions may be forced to find their
functions in a different package, so there may be a measurable practical
cost.
In many cases where an extension symbol FOO is simply expected to have
been directly available (due to :USE "LISP"), it will work to just just
do (IMPORT 'new-home-package-for-foo:FOO) where the user's package is
declared.
In many cases where an extension symbol FOO is used by explicit package
prefix, such as LISP:FOO, it should be easy to search for `LISP:FOO' or
even `LISP:' to find the cases.
Cost of Non-Adoption:
The potential for the LISP package to be adulterated and for supposedly
portable programs to have difficulty getting a foothold in some
implementations will be `noticeably non-zero'.
Benefits:
Portability of some programs will be enhanced.
Aesthetics:
This change probably supports the naive expectation of most programmers
writing portable code.
Discussion:
This proposal basically affects what implementors are allowed to do;
it says that portable programs can rely on a standard initial package
structure with the same symbols in it. A separate proposal,
LISP-SYMBOL-REDEFINITION, discusses the restrictions on portable
programs as far as redefining LISP symbols.
Whether the USER package may contain symbols other than those
specified in the standard was controversial. The smart programmer
of portable code will never rely on the contents of the
USER package. However, if someone wants a completely empty
package that uses only Lisp, it's easy and portable to create one.
While it would improve portability slightly to disallow additional
internal
symbols in the LISP package (since it affects what DO-SYMBOLS will do)
explicitly prohibiting a common practice didn't seem like the best way
to discourage a possibly troublesome implementation technique.
Implementors should be especially careful about accidentally
exporting unwanted additional definitions for symbols,e.g., a variable
definition for EVALHOOK which might show through because of
an unintended name collision.
It is likely that the recently included portions of the standard (CLOS
and
the signal mechanism) will reside in their own packages. These externally
defined packages should have the same constraints as outlined for
the LISP package here.
There has been a suggestion that vendor-specific extensions should
be placed in a package named like ACME-COMMON-LISP for the "Acme"
company.
A registry of packages (as well as features, modules and other global
names) would be useful, although probably not a part of the language
standard, per se.
∂07-Oct-88 2304 CL-Cleanup-mailer Re: Issue: STREAM-INFO (Version 5)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:04:29 PDT
Received: from Semillon.ms by ArpaGateway.ms ; 07 OCT 88 23:00:55 PDT
Date: 7 Oct 88 23:01 PDT
From: masinter.pa@Xerox.COM
Subject: Re: Issue: STREAM-INFO (Version 5)
In-reply-to: masinter.pa's message of 6 Oct 88 16:16 PDT
To: masinter.pa@Xerox.COM
cc: Scott.Fahlman@B.GP.CS.CMU.EDU, dick@wheaties.ai.mit.edu (Richard C.
Waters), CL-Cleanup@sail.stanford.edu
Message-ID: <881007-230055-1825@Xerox>
There's a bit about this proposal that bothers me, but it mainly has to do
with the interactions with the changes that the character committee is
thinking about with regard to extended character sets.
What is the relationship between graphic-char-p and the notion that the
printed width of the character is non-NIL (and non-zero?).
As a matter of form, the writeup commits the sin of arguing for the
proposal in the middle of describing it; the proposal name is too generic
and not really appropriate to the problem. The Problem is
PRETTY-PRINT-WIDTH-SUPPORT or some such.
Its important to bring this up at the meeting because of the interaction
with the character proposal, however.
∂07-Oct-88 2343 CL-Cleanup-mailer Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 7)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:43:05 PDT
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01290g; Fri, 7 Oct 88 23:41:51 PDT
Received: by bhopal id AA03475g; Fri, 7 Oct 88 23:40:12 PDT
Date: Fri, 7 Oct 88 23:40:12 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8810080640.AA03475@bhopal>
To: cl-cleanup@sail.stanford.edu
Subject: Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (version 7)
Changed names in accord with previous msg.
Use "type-equivalent" rather than "same type specifier" in item 2, since
this isn't dependent on whether (unsigned-byte 8) or (mod 256) is used.
Fixed up a couple of awkward wordings.
Remaining questions for Moon:
-- Item 3 in the proposal has something odd with the description of <x>,
and I'm not sure I know what you really mean. It says something like
"... iff <x> is a complex number of a {certain} representation, or
if <x> is of any subtype of that representation." What would this
mean for an implementation that has, say, two distinct specialized
representations for complex part types -- (signed-byte 8) and
(signed-byte 32) -- what should the values of the following be:
(typep #c(15 99) '(complex (signed-byte 8)) ==> ??
(typep #c(15 99) '(complex (signed-byte 32)) ==> ??
Or, did you intend item 3 to depend on the understanding in the
succeeding item 5?
-- The second paragraph of the Rationale didn't parse (as English); I
made a stab a breaking the run-on sentence into two, but you ought
to take another look at it.
-- JonL --
!
Issue: ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS
References: Data types and Type specifiers: CLtL p. 11; Sect. 4.5, p.45
TYPEP and SUBTYPEP; CLtL Sect. 6.2.1, p.72
ARRAY-ELEMENT-TYPE, CLtL p. 291
The type-specifiers ARRAY, COMPLEX, SIMPLE-ARRAY, and VECTOR
Category: CHANGE
Edit history: Version 1, 13-May-88, JonL
Version 2, 23-May-88, JonL
(typo fixes, comments from moon, rearrange some discussion)
Version 3, 02-Jun-88, JonL
(flush alternate proposal ["flush-upgrading"]; consequently,
move more of discussion back to discussion section.
Version 4, 01-Oct-88, Jan Pedersen & JonL
(reduce discussion, and "cleanup" wordings)
(Version 5 edit history missing)
Version 6, 6-Oct-88, Moon
(fix typos, cover subtypep explicitly, add complex,
change name of UPGRADE-ARRAY-ELEMENT-TYPE)
Version 7, 7-Oct-88, JonL (more name and wording changes).
Problem description:
CLtL occasionally draws a distinction between type-specifiers "for
declaration" and "for discrimination". Many people are confused by
this situation, which may be one of the more insidious flaws in the
current CL design. A consequence of this "flaw" is that a variable
declared to be of type <certain-type> and all of whose assigned objects
are created in accordance with that type, may still have *none* of its
values ever satisfy the typep predicate with that type-specifier.
One type-specifier with this property is
(ARRAY <element-type>)
for various implementation dependent values of <element-type>. For
example, in most implementations of CL, an array X created with an
element-type of (SIGNED-BYTE 5) will, depending on the vendor, either
satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 8))), or
(TYPEP X '(ARRAY T))
but (almost) never will it satisfy
(TYPEP X '(ARRAY (SIGNED-BYTE 5))).
Proposal: (ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS:UNIFY-UPGRADING)
Eliminate the distinction between type-specifiers "for declaration" and
"for discrimination". Change the meaning of the <element-type> in the
ARRAY type-specifier and its subtypes, and in the COMPLEX type-specifier,
to be the same for TYPEP and SUBTYPEP as for TYPE declarations.
Specify how SUBTYPEP behaves on these type-specifiers. Add a function
to provide access to the implementation-dependent set of array types
and another function to provide access to the implementation-dependent
set of complex number types.
1. Eliminate references to the distinction between types "for declaration"
and "for discrimination" in the discussion of array and complex
type-specifiers. This would include documentation patterned after CLtL:
a.) The discussion in section 4.5, pp. 45-7
b.) p. 291, the sentence begining "This set may be larger than the set
requested when the array was created; for example . . ."
Instead, (ARRAY <type>) always means all arrays that can result by specifying
<type> as the :ELEMENT-TYPE argument to the function MAKE-ARRAY, and
(COMPLEX <type>) always means all complex numbers that can result by
giving numbers of type <type> to the function COMPLEX, plus all other
complex numbers of the same specialized representation.
2. Change the meaning of (TYPEP <x> '(ARRAY <type>)) to be true if and
only if <x> is an array of the most specialized representation capable
of holding elements of type <type>. In other words, it is true if and
only if <x> is an array and (ARRAY-ELEMENT-TYPE <x>) is type-equivalent
to (ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE <type>)).
Do the same for SIMPLE-ARRAY and VECTOR.
3. Change the meaning of (TYPEP <x> '(COMPLEX <type>)) to be true if
and only if <x> is a complex number of the most specialized
representation capable of holding parts of type <type>, or if <x> is of
any subtype of that representation. Both the real and imaginary parts
must satisy (TYPEP <real-or-imag-part> '<type>).
4. Define that for all type-specifiers <type1> and <type2>, other than *,
(ARRAY <type1>) and (ARRAY <type2>) are either equivalent or disjoint,
depending on whether they use the same specialized representation or
distinct representations. This defines the behavior of SUBTYPEP.
5. Define that for all type-specifiers <type1> and <type2>, other than *,
(SUBTYPEP '(COMPLEX <type1>) '(COMPLEX <type2>)) is T T if they use the
same specialized representation, T T if they use distinct specialized
representations but (SUBTYPEP '<type1> '<type2>) is true, and NIL T
otherwise.
6. Require that the resultant ARRAY-ELEMENT-TYPE from a call to
MAKE-ARRAY is independent of any argument to MAKE-ARRAY except for the
:ELEMENT-TYPE argument. Thus the set of specialized array
representations must be consistent between single-dimensional and
multi-dimensional, simple and non-simple, short and long arrays.
7. Add the function IMPLEMENTED-ARRAY-ELEMENT-TYPE of one argument
which returns the same result as:
(DEFUN IMPLEMENTED-ARRAY-ELEMENT-TYPE (TYPE)
(ARRAY-ELEMENT-TYPE (MAKE-ARRAY 0 :ELEMENT-TYPE TYPE)))
The type specifiers (ARRAY <type1>) and (ARRAY <type2>), where neither
<type1> nor <type2> is *, are equivalent if <type1> and <type2> produce
the same value from IMPLEMENTED-ARRAY-ELEMENT-TYPE, and disjoint
otherwise.
8. Add the function IMPLEMENTED-COMPLEX-PART-TYPE of one argument
which returns the part type of the most specialized complex number
representation that can hold parts of the given argument type.
Test cases:
Let <aet-x> and <aet-y> be two distinct type specifiers that are
definitely not type-equivalent in a given implementation, but for which
make-array will return an object of the same array type. This will be
an implementation dependent search, but in every implementation that
the proposer has tested, there will be some such types; often,
(SIGNED-BYTE 5) and (SIGNED-BYTE 8) will work.
Thus, in each case, both of the following forms return T T:
(subtypep (array-element-type (make-array 0 :element-type '<aet-x>))
(array-element-type (make-array 0 :element-type '<aet-y>)))
(subtypep (array-element-type (make-array 0 :element-type '<aet-y>))
(array-element-type (make-array 0 :element-type '<aet-x>)))
To eliminate the distinction between "for declaration" and "for
discrimination" both of the following should be true:
[A]
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-y>))
Since (array <aet-x>) and (array <aet-y>) are different names for
exactly the same set of objects, these names should be type-equivalent.
That implies that the following set of tests should also be true:
[B]
(subtypep '(array <aet-x>) '(array <aet-y>))
(subtypep '(array <aet-y>) '(array <aet-x>))
Additionally, to show that un-equivalent type-specifiers that use the
same specialized array type should be equivalent as element-type
specifiers, the following type tests should be true:
[C]
(typep (make-array 0 :element-type '<aet-y>)
'(array <aet-x>))
(typep (make-array 0 :element-type '<aet-x>)
'(array <aet-y>))
Rationale:
This proposal legitimizes current practice, and removes the obscure and
un-useful distinction between type-specifiers "for declaration" and
"for discrimination". The suggested changes to the interpretation of
array and complex type-specifiers follow from defining type-specifiers
as names for collections of objects, on TYPEP being a set membership
test, and SUBTYPEP a subset test on collections of objects.
The small differences between the specification for ARRAY and the
specification for COMPLEX are necessary because there is no creation
function for complexes which allows one to specify the resultant type
independently of the types of the parts. Thus in the case of COMPLEX
we must refer to the type of the two parts, and to the fact that a
number can be a member of more than one type. Note that:
(SUBTYPEP '(COMPLEX SINGLE-FLOAT) '(COMPLEX FLOAT))
is true in all implementations, but
(SUBTYPEP '(ARRAY SINGLE-FLOAT) '(ARRAY FLOAT))
is only true in implementations that do not have a specialized array
representation that can hold single-floats but not other floats.
Current Practice:
Every vendor's implementation that the proposer has queried has a
finite set of specialized array representations, such that two
non-equivalent element types can be found that use the same specialized
array representation; this includes Lucid, Vaxlisp, Symbolics, Franz,
and Xerox. Most implementations fail tests [A] and [C] part 1, but pass
tests [A] and [C] part 2; this is a consequence of implementing the
distinction between "for declaration" and "for discrimination". Lucid
and Xerox both pass test [B], and the other vendors fail it.
No vendor that the proposer has queried has any specialized representation
for complexes.
Cost to Implementors:
This proposal is an incompatible change to the current language
specification, but only a small amount of work should be required in
each vendor's implementation of typep and subtypep.
Cost to Users:
Because of the prevalence of confusion in this area, it seems unlikely
that any user code will have to be changed. In fact, it is more likely
that some of the vendors will cease to get bug reports about make-array
returning a result that isn't of "the obvious type". Since the change
is incompatible, some user code might have to be changed.
Cost of non-adoption:
Continuing confusion in the user community.
Benefits:
It will greatly reduce confusion in the user community. The fact that
(make-array <n> :element-type '<type>) frequently is not of type
(array <type>) has been very confusing to almost everyone. That is, in
practice, the distinction between "for declaration" and "for
discrimination" has been a disaster.
Esthetics:
Reducing the confusing distinction between type-specifiers "for
declaration" and "for discrimination" is a simplifying step -- it is a
much simpler rule to state that the type-specifiers actually describe
the collections of data they purport to name. Thus this is a step
towards increased elegance.
Discussion:
To get a sense of how the community is confused, see the arpanet mailing
list for Common Lisp, in a series of exchanges started on Thu,
17 Dec 87 10:48:05 PST by Jeff Barnett <jbarnett@nrtc.northrop.com>
under the subject line of "Types in CL". Also see the exchange started
Wed, 6 Jan 88 23:21:16 PST by Jon L White <edsel!jonl@labrea.stanford.edu>
under the subject line of "TYPEP warp implications".
Many senior implementors at Lucid favor this proposal. In network mail
"Date: Sat, 9 Jan 1988 15:54 EST" Rob McLaughlin favored the gist of this
proposal -- namely that upgrading should be continued, and that TYPEP
should be fixed. Here is an excerpt of his words:
There are two obvious solutions, one of which has already been
proposed:
-- Make the mapping more direct. Eliminating "array element type
upgrading" would be an instance of this.
-- Make the mapping explicitly ill-defined in a more useful way.
I think we need to do the latter because the former won't work. I
don't see how to eliminate "array element type upgrading" without
creating more problems [than] we solve. . . .
My conclusion [JonL's] is that it isn't array types that are wrong,
it is the understanding of the meaning of TYPEP that is wrong.
Many persons are in favor of the permission to upgrade; but they would
not like to see CL become a language like C where there are a
prescribed set of kinds of arrays that must be implemented (e.g, "int",
"long int", "single", "double" etc), and no others can exist. In short,
no one would want to gain portability at the expense of limiting the
language to the architectural features of the hardware on which it was
first implemented.
It may also be the case that portability will be improved since the
identity
(typep (make-array N :element-type '<type>) '(array <type>)) will be
observed.
∂07-Oct-88 2351 CL-Cleanup-mailer Issue Status (finally!!)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 7 Oct 88 23:51:08 PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 07 OCT 88 23:49:23 PDT
Date: 7 Oct 88 23:49 PDT
From: masinter.pa@Xerox.COM
Subject: Issue Status (finally!!)
To: cl-cleanup@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <881007-234923-1851@Xerox>
With much help from Kent, I've managed to make it through the list of
issues, mailing out the ones that looked like they were ready.
Tomorrow, I will go through, make sure I have hardcopy of all of the
released issues, look for ones that look like they should be released (in
DRAFT form, if necessary) to X3J13. I'm especially concerned about
dependencies, e.g., IN-PACKAGE-FUNCTIONALITY goes with DEFPACKAGE, but
DEFPACKAGE hasn't been released. Also, the STREAM-INFO proposal should be
released in draft format because it interacts with the character proposal.
+ released for this meeting
++ released for a previous meeting
* possibly releasable in DRAFT format
- deferred, tabled, postponed, no immediate action likely
- - - - - - - - - - -
* ADJUST-ARRAY-NOT-ADJUSTABLE (Version 1, 22-Apr-87)
What does adjust-array do on non-adjustable arrays?
Comments: Several critical comments came back. A rewrite is in order.
+ ALIST-NIL (Version 4, 01-Oct-88)
remove special provision for NIL in alists
+ ARGUMENTS-UNDERSPECIFIED (Version 4, 21-Sep-88)
Clarify various ranges missing from CLtL
* ARRAY-TYPE-ELEMENT-TYPE-SEMANTICS (Version 5, 01-Oct-88)
upgrading of array element types
Comments: pending response to presentational remarks
* CLOSED-STREAM-OPERATIONS (Version 1, 26-Aug-88)
What operations are legal on closed streams?
Comments: Needs rewrite based on ensuing discussion.
* COERCE-INCOMPLETE (Version 1, 26-Feb-88)
Extend COERCE to handle default coercions?
Extend COERCE to take an optional FROM-TYPE?
Depends on TYPE-OF-UNDERCONSTRAINED because of dependence on
TYPE-OF.
- CONSTANT-SIDE-EFFECTS (no proposal)
It is an error to do destructive operations on constants
in code, defconstant.
Deferred to Compiler Committee; no action there?
+ CONTAGION-ON-NUMERICAL-COMPARISONS (Version 1, 14-Sep-88)
allow numeric comparison of mixed types to be transitive
++ DECLARATION-SCOPE (Version 2, 2-Feb-88)
what is the scope of declarations?
Distributed to X3J13/June 88.
Some ensuing discussion without resolution
+ DECLARE-FUNCTION-AMBIGUITY (Version 3, 30-Sep-88)
(DECLARE (FUNCTION ...)) = (DECLARE (FTYPE ...)) or
(DECLARE (TYPE FUNCTION ...))
+ DECLARE-TYPE-FREE (Version 6, 6-Oct-88)
(DECLARE (TYPE x)) when not binding X.
nits on "discussion"
+ DECODE-UNIVERSAL-TIME-DAYLIGHT (Version 2, 30-Sep-88)
What happens with the time-zone in DECODE-UNIVERSAL-TIME?
- DEFMACRO-BODY-LEXICAL-ENVIRONMENT (no proposal)
What is the lexical environment of DEFTYPE, DEFINE-SETF bodies?
Deferred to the Compiler committee, renamed there.
* DEFPACKAGE (Version 4, 01-Oct-88)
ok technically; wording is too sloppy
+ DEFSTRUCT-CONSTRUCTOR-KEY-MIXTURE (Version 2, 21-Sep-88)
Allow &OPTIONAL, &KEY and &AUX in defstruct constructors.
++ DEFSTRUCT-DEFAULT-VALUE-EVALUATION (Version 1, 13-May-88)
From issues file: "The default value in a DEFSTRUCT slot is not evaluated
unless it is needed in the creation of a particular structure instance.
If it is never needed, there can be no type-mismatch error, even if the
type
of the slot is specified, and no warnings should be issued." See p305
released X3J13/June 88
+ DEFSTRUCT-PRINT-FUNCTION-INHERITANCE (Version 2, 15-Sep-88)
inheritance of :PRINT-FUNCTION for DEFSTRUCTs
* DEFSTRUCT-REDEFINITION (Version 1, 26-Jul-88)
comments need to address inlining issues.
need to be able to re-load the identical definition.
+ DEFSTRUCT-SLOTS-CONSTRAINTS-NAME (Version 3, 23-Sep-88)
An error for two slots in a single DEFSTRUCT to have the same name.
* DESCRIBE-INTERACTIVE (Version 2, 23-Sep-88)
Is DESCRIBE allowed to be interactive?
maybe switch sense
* DOTTED-MACRO-FORMS (Version 2, 01-Oct-88)
Can a macro actual argument end in dotted form?
- DYNAMIC-VALUE-EXTENT (aka STACK-LET)
* ELIMINATE-FORCED-CONSING (Version 3, 31-Aug-88)
(specify target to sequence functions)
* EQUAL-STRUCTURE (Version 5, 01-Oct-88)
leave EQUAL alone, eh?
++ EVAL-OTHER (Version 2, 08-Jun-88)
Make random types self-eval.
Distributed for June 88 X3J13
* EXIT-EXTENT (Version 2, 1-Oct-88)
lifetime of non-local exit
+ EXPT-RATIO (Version 1, 04-Oct-88)
(expt -1 3/2)
- FILE-LENGTH-PATHNAME (no proposal)
From Issues file: "Generalize FILE-LENGTH to accept any filename,
not just an open file stream. Let it take a keyword argument
:ELEMENT-TYPE defaulting to STRING-CHAR for non-stream arguments
and to the element-type of the stream for a stream argument." See p425
- FILE-WRITE-DATE-IF-NOT-EXISTS (no proposal)
What does file-write-date do if no such file?
deferred to Errors committee but not handled there
+ FIXNUM-NON-PORTABLE (Version 3, 23-Sep-88)
Require fixnum to be at least (SIGNED-BYTE 16); remove BIGNUM.
+ FORMAT-E-EXPONENT-SIGN (Version 2, 02-Oct-88)
(format NIL "~E" 1.0) => "1.0e+1", unlike PRIN1
- FORMAT-NEGATIVE-PARAMETERS (no proposal)
From mail of 19-May-87: "format parameters are assumed to
be non-negative integers except as explicitly stated"
deferred to Errors committee but not handled there.
relationship to RANGE-OF-COUNT-KEYWORD?
** FORMAT-PRETTY-PRINT (Version 5, 02-Oct-88)
what *PRINT-... variables does format use, rebind?
++ FUNCTION-CALL-EVALUATION-ORDER (Version 1, 22-Mar-88)
(foo (setf (symbol-function 'foo) ...))
Released to X3J13 June 88
* FUNCTION-COERCE-TIME (Version 2, 16-Sep-88)
(defun foo (x) (setf (symbol-function x) ...) (mapcar 'foo ...)
* FUNCTION-COMPOSITION (Version 2, 05-Oct-88)
typo; (COMPOSE) = #'VALUES
* FUNCTION-DEFINITION (Version 1, 23-Jun-88)
extract LAMBDA from FUNCTION if possible.
- FUNCTION-SPECS (no proposal)
add "function specs" for DEFUN, TRACE, etc.)
deferred to separate committee
* FUNCTION-TYPE-ARGUMENT-TYPE-SEMANTICS (Version 2, 13-Sep-88)
multiple declarations? antimonotonic. FTYPE vs TYPE.
+ FUNCTION-TYPE-REST-LIST-ELEMENT (Version 4, 2-Oct-88)
+ is (FUNCTION (&REST NUMBER) NUMBER)
- GC-MESSAGES (Version 1, 23-Apr-87)
portable way to turn off unwanted messages?
- GET-MACRO-CHARACTER-READTABLE (no proposal yet)
CLtL example but not text implies NIL valid readtable arg
* HASH-TABLE-ACCESS (Version 1, 13-Sep-88)
add HASH-TABLE-TEST, etc.
- HASH-TABLE-GC (no proposal)
add keyword to MAKE-HASH-TABLE to allow keys to be gc'd.
* HASH-TABLE-KEY-MODIFICATION (Version 1, 12-Sep-88)
What happens if you modify component of key to EQUAL hash table?
* HASH-TABLE-PACKAGE-GENERATORS (Version 1, 7-Oct-88)
support for iterating over hash tables, packages
* HASH-TABLE-PRINTED-REPRESENTATION (Version 2, 8-Jun-88)
make hash tables print as #H
Some debate about how to do this "right"
+ HASH-TABLE-TESTS (Version 1, 26-Sep-88)
add :TEST 'EQUALP
+ IN-PACKAGE-FUNCTIONALITY (Version 2, 7-Oct-88)
make IN-PACKAGE not create package
discuss after DEFPACKAGE
+ LAMBDA-FORM (Version 3, 02-Oct-88)
allow LAMBDA as car-of-form
- LET-BY-NAME (no proposal)
rename SYMBOL-MACROLET to LET-BY-NAME and change its semantics
to bind the expansion to an environment.
- LET-TOP-LEVEL
(what's top level? Can DEFUN appear not-top-level?)
* LISP-SYMBOL-REDEFINITION (version 2)
Is it legal to redefine symbols in the LISP package?
* LIST-TYPE-SPECIFIER (Version 1, 28-Jun-88)
add new type specifiers (LIST SYMBOL) or (LIST-OF SYMBOL) etc.
radically different ideas about what it should mean
- LOAD-TIME-EVAL (Version 4, 2-Feb-88)
=> cl-compiler. Some confusion about which committee has it
* MAKE-PACKAGE-USE-DEFAULT (version 1, 6-Oct-88)
What's the default for :USE in MAKE-PACKAGE (and DEFPACKAGE)
what's the proposal?
* MAPPING-DESTRUCTIVE-INTERACTION (Version 1, 7-Mar-88)
interaction of destructive operations on mapping functions
needs more clarification
+ NTH-VALUE (Version 3, 05-Oct-88)
(NTH (MULTIPLE-VALUE-LIST ...))
* PACKAGE-CLUTTER (Version 4, 7-Oct-88)
Comments: Some wording still to be haggled out.
* PACKAGE-DELETION (Version ?, ...)
renamed from KILL-PACKAGE
give function for deleting a package
* PATHNAME-CANONICAL-TYPE (Version 1, 07-Jul-88)
allow PATHNAME-TYPE to talk portably about "lisp source" or "compiled
lisp"
A new proposal is needed to accomodate discussion which followed.
* PATHNAME-COMPONENT-CASE (Version 1, 01-Jul-88)
dealing with case-sensitive file systems sensibly
* PATHNAME-SUBDIRECTORY-LIST (Version 2, 5-Jul-88)
make hierarchical directories visible as lists
* PATHNAME-SYNTAX-ERROR-TIME (Version 1, 07-Jul-88)
when do illegal pathname components get checked?
+ PATHNAME-TYPE-UNSPECIFIC (Version 1, 27-Jun-88)
* PATHNAME-WILD (Version 2, 06-Oct-88)
* PEEK-CHAR-READ-CHAR-ECHO (Version 2, 23-Jun-88)
Interaction between PEEK-CHAR, READ-CHAR and streams made by
MAKE-ECHO-STREAM.
(Has two proposals, need to pick one.)
* PRINT-CIRCLE-STRUCTURE (Version 2, 5-Oct-88)
* PROCLAIM-LEXICAL (Version 8, 06-Oct-88)
Add LEXICAL, GLOBAL, and CONSTANT proclamations.
still some open issues
- PROCLAIM-SCOPE (Version 1, 26-Aug-88)
way to restrict PROCLAIM to files?
- PROMPT-FOR (Version 1, 11-Mar-87)
want general way to ask a user a question?
* RANGE-OF-COUNT-KEYWORD (Version 2, 22-Aug-88)
needs minor corrections
+ RANGE-OF-START-AND-END-PARAMETERS (Version 1, 14-Sep-88)
* REMF-DESTRUCTION-UNSPECIFIED (Version 2, 30-Oct-87)
what can programs rely on about side effects of REMPROP?
* REQUIRE-PATHNAME-DEFAULTS (Version 2, 19 Sep 88)
REQUIRE can't work; make it declarative.
needs minor rework
- REST-LIST-ALLOCATION (no proposal)
Clarify whether (APPLY #'LIST X) is the same as (COPY-LIST X) or (IDENTITY
X).)
- REST-LIST-EXTENT (Version 1, 10-Apr-88)
+ RETURN-VALUES-UNSPECIFIED (Version 4, 7-Oct-88)
* ROOM-DEFAULT-ARGUMENT (Version 1, 12-Sep-88)
say more about what ROOM does
* SEQUENCE-FUNCTIONS-EXCLUDE-ARRAYS (Version 6, 06-Oct-88)
revived the MODIFIED option in Version 6.
++ SETF-FUNCTION-VS-MACRO (Version 3, 4-Nov-87)
* SETF-SUB-METHODS (Version 5, 6-Oct-88)
Moon OK?
- SPECIAL-VARIABLE-TEST (Version 1, 7-Mar-88)
subsumed by new proposal
- STANDARD-CLASS-OVERHEAD
withdrawn?
+ STANDARD-INPUT-INITIAL-BINDING (Version 8, 08-Jul-88)
remove requirements for *ERROR-OUTPUT* initial binding,
specify more possibilities
+ STEP-ENVIRONMENT (Version 3, 20-Jun-88)
STEP, TIME evalute in current environment
+ STREAM-ACCESS (Version 1, 17-Jul-88)
Define stream accessors like BROADCAST-STREAM-STREAMS
* STREAM-CAPABILITIES (version 1, 05-Jul-88)
add new predicates -SAME- -INTERACTIVE-P to streams.
* STREAM-INFO
really PRETTY-PRINT-WIDTH-SUPPORT: find out how
wide things are
+ SUBTYPEP-TOO-VAGUE (Version 7, 7-Oct-88)
* SYMBOL-MACROLET-DECLARE (Version 1, 12-Sep-88)
(SYMBOL-MACROLET (X ...) (LOCALLY (DECLARE (SPECIAL X)) ...)
* SYMBOL-MACROLET-SEMANTICS (Version 4, 22-Sep-88)
* SYNTACTIC-ENVIRONMENT-ACCESS (Version 1, 02-Oct-88)
+ TAGBODY-CONTENTS (Version 4, 05-Oct-88)
* TAIL-RECURSION-OPTIMIZATION (Version 2, 01-Oct-88)
* TAILP-NIL (Version 2, 13-Sep-88)
* TEST-NOT-IF-NOT (Version 2, 05-Oct-88)
* TRUENAME-SYNTAX-ONLY (Version 1, 12-Sep-88)
* TYPE-OF-UNDERCONSTRAINED (no proposal)
* UNREAD-CHAR-AFTER-PEEK-CHAR (Version 1, 29-Jul-88)
+ VARIABLE-LIST-ASYMMETRY (Version 2, 04-Aug-88)
++ WITH-OUTPUT-TO-STRING-APPEND-STYLE